NTN Rel-17

RAN1#102-e

8.4 Solutions for NR to support non-terrestrial networks (NTN)

Please refer to RP-201256 for detailed scope of the WI

R1-2007385 Session notes for 8.4 (Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Ericsson)

R1-2005306 NR_NTN_solutions work plan THALES

R1-2006676 NR NTN Reference scenarios definition for Rel-17 normative phase THALES

8.4.1 Timing relationship enhancements

R1-2005265 Discussion on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2005495 Timing relationship enhancements for NR-NTN MediaTek Inc.

R1-2005548 NR-NTN: Timing Relationship Enhancements Fraunhofer IIS, Fraunhofer HHI

R1-2005573 Calculation of timing relationship offsets Sony

R1-2005706 Timing relationship enhancement for NTN CATT

R1-2005833 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2005873 On timing relationship enhancements for NTN Intel Corporation

R1-2005963 Discussion on timing relationship for NTN ZTE

R1-2006029 discusson on timing relationship enhancement OPPO

R1-2006144 On Timing relationship enhancements Samsung

R1-2006210 Discussion on timing relationship enhancements for NTN CMCC

R1-2006325 Timing relationship enhancement for NTN Panasonic Corporation

R1-2006358 Discussion on timing relationships for NTN ETRI

R1-2006378 Discussions on timing relationship enhancements in NTN LG Electronics

R1-2006421 DL-UL timing relationship for NTN operation Nokia, Nokia Shanghai Bell

R1-2006464 On basic assumptions and timing relationship enhancements for NTN Ericsson

R1-2006519 On Timing Relationship Enhancement in NTN Apple

R1-2006589 Discussion on the timing relationship for NTN Beijing Xiaomi Mobile Software

R1-2006640 Discussion on timing relationship enhancements for NTN Asia Pacific Telecom co. Ltd

R1-2006804 Enhancements on Timing Relationship for NTN Qualcomm Incorporated

R1-2006855 Timing relationship enhancements to support NTN CAICT

[102-e-NR-NTN-Timing-Rel-Enh] – Xingqin (Ericsson)

Email discussion/approval on timing relationship enhancements until 8/20; address any remaining aspects by 8/25

R1-2006981 Feature lead summary on timing relationship enhancements Moderator (Ericsson)

R1-2007074 Feature lead summary#2 on timing relationship enhancements Moderator (Ericsson)

R1-2007176 Feature lead summary#3 on timing relationship enhancements Moderator (Ericsson)

R1-2007323 Feature lead summary#4 on timing relationship enhancements Moderator (Ericsson)

Agreement:

· Introduce K_offset to enhance the following timing relationships:

o The transmission timing of DCI scheduled PUSCH (including CSI on PUSCH).

o The transmission timing of RAR grant scheduled PUSCH.

o The transmission timing of HARQ-ACK on PUCCH.

o The CSI reference resource timing.

o The transmission timing of aperiodic SRS.

· Note: Additional timing relationships that require K_offset of the same or different values can be further identified.

Agreement:

For Koffset used in initial access, the information of Koffset is carried in system information.

FFS implicit and/or explicit signaling of Koffset in system information.
FFS a cell specific Koffset value used in all beams of a cell and/or each beam in a cell uses a beam-specific Koffset value.
FFS whether/how to update Koffset after initial access.

8.4.2 Enhancements on UL time and frequency synchronization

R1-2005266 Discussion on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2005496 UL Time and Frequency Synchronisation for NR-NTN MediaTek Inc., Eutelsat

R1-2005502 On UL time and frequency synchronization enhancements for NTN Ericsson

R1-2005574 Enhancement for UL time synchronization Sony

R1-2005707 Discussion for UL time and frequency compensation CATT

R1-2005834 Discussion on NTN TA indication Lenovo, Motorola Mobility

R1-2005874 On UL time and frequency synchronization for NTN Intel Corporation

R1-2005902 Discussion on PRACH sequences Mitsubishi Electric RCE

R1-2005964 Discussion on UL synchronization for NTN ZTE

R1-2006030 discussion on UL time and frequency synchronization OPPO

R1-2006145 On Enhancements on UL time and frequency synchronization Samsung

R1-2006211 Enhancements on uplink timing advance for NTN CMCC

R1-2006326 UL timing advance and frequency synchronization for NTN Panasonic Corporation

R1-2006359 Discussion on UL timing advance for NTN ETRI

R1-2006379 Discussions on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2006422 Discussion on UL time and frequency synchronization for NTN Nokia, Nokia Shanghai Bell

R1-2006520 On Timing Advance for NTN Apple

R1-2006603 Discussion on UL time and frequency synchronization for NTN Beijing Xiaomi Mobile Software

R1-2006619 On UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2006641 Discussion on UL time and frequency synchronization for NTN Asia Pacific Telecom co. Ltd

R1-2006674 Considerations on UL timing and frequency synchronization THALES

R1-2006805 UL time and frequency synchronization for NTN Qualcomm Incorporated

R1-2006856 Considerations on Enhancements on UL Time Synchronization in NTN CAICT

[102-e-NR-NTN-UL-Time-Freq-Sync-Enh] – Baptiste (Thales)

Email discussion/approval on UL time and frequency synchronization until 8/21; address any remaining aspects by 8/27

R1-2007057 Feature lead summary on enhancements on UL timing and frequency synchronization Moderator (Thales)

R1-2007217 Feature lead summary#2 on enhancements on UL timing and frequency synchronization Moderator (Thales)

R1-2007290 Feature lead summary#3 on enhancements on UL timing and frequency synchronization Moderator (Thales)

Agreement:

In Rel-17 NR NTN, at least support UE which can derive based on its GNSS implementation one or more of:

its position
a reference time and frequency

And, based on one or more of these elements together with additional information (e.g., serving satellite ephemeris or timestamp) signalled by the network, can compute timing and frequency, and apply timing advance and frequency adjustment at least for UE in RRC idle/inactive mode.
FFS: Details on additional information signalled from network

Agreement:

In case of GNSS-assisted TA acquisition in RRC idle/inactive mode, the UE calculates its TA based on the following potential contributions:

The User specific TA which is estimated by the UE:

Option 1: The User specific TA is estimated by the UE based on its GNSS acquired position together with the serving satellite ephemeris indicated by the network:

FFS: Details on serving satellite ephemeris indication

Option 2: The User specific TA is estimated by the UE based on the GNSS acquired reference time at UE together with reference time as indicated by the network

The Common TA if indicated by the network:

FFS: The need and details of Common TA indication

FFS: The TA margin, if needed and indicated by the network (in order to account for the TA estimation uncertainty)

8.4.3 Enhancements on HARQ

R1-2005267 Discussion on HARQ enhancement for NTN Huawei, HiSilicon

R1-2005312 Discussion on HARQ for NTN Nomor Research GmbH, Thales

R1-2005497 HARQ in NR-NTN MediaTek Inc.

R1-2005575 Enhancements on delay-tolerant HARQ Sony

R1-2005708 HARQ operation enhancement for NTN CATT

R1-2005835 Enhancements on HARQ for NTN Lenovo, Motorola Mobility

R1-2005875 On HARQ enhancements for NTN Intel Corporation

R1-2005965 Discussion on HARQ for NTN ZTE

R1-2006031 discussion on HARQ enhancement OPPO

R1-2006146 On Enhancements on HARQ Samsung

R1-2006212 Enhancements on HARQ for NTN CMCC

R1-2006327 HARQ enhancement for NTN Panasonic Corporation

R1-2006360 Discussion on HARQ Enhancements for NTN ETRI

R1-2006380 Discussions on HARQ enhancements in NTN LG Electronics

R1-2006423 Discussion on HARQ stalling avoidance Nokia, Nokia Shanghai Bell

R1-2006465 On HARQ enhancements for NTN Ericsson

R1-2006521 On HARQ Enhancement for NTN Apple

R1-2006604 Discussion on the enhancement on HARQ for NTN Beijing Xiaomi Mobile Software

R1-2006642 Discussion on HARQ enhancements for NTN Asia Pacific Telecom co. Ltd

R1-2006806 Enhancements on HARQ for NTN Qualcomm Incorporated

R1-2006857 Enhancements on HARQ to support NTN CAICT

[102-e-NR-NTN-HARQ-Enh] – Nan (ZTE)

Email discussion/approval on HARQ enhancements until 8/20; address any remaining aspects by 8/26

R1-2007056 Summary of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

R1-2007196 Summary#2 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

R1-2007311 Summary#3 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

Agreement:

Enabling/disabling on HARQ feedback for downlink transmission should be at least configurable per HARQ process via UE specific RRC signaling

Agreement:

The extension of maximal HARQ process number can be considered with following assumptions:

· The maximal supported HARQ process number is up to 32.

· FFS: Support on the maximal HARQ process number is up to UE capability

· Minimizing the impacts on specification and scheduling

8.4.44 Other

Including the list of topics to specify if beneficial and needed

R1-2005268 Discussion on other design aspects for NTN Huawei, HiSilicon

R1-2005311 Considerations on PAPR requirements for NR NTN downlink transmission THALES

Withdrawn

R1-2005313 Study Cases for System-Level Simulations in NTN WI Nomor Research GmbH, Thales

R1-2005498 Other Aspects of NR-NTN MediaTek Inc.

R1-2005547 NR-NTN: Physical Random Access Channel Fraunhofer IIS, Fraunhofer HHI

R1-2005576 Discussion on beam management and BWP operation for NTN Sony

R1-2005709 Discussion for beam management and feeder link switch enhancement CATT

R1-2005836 Discussion on NTN beam management Lenovo, Motorola Mobility

R1-2005876 On pre-compensation capabilities and beam management for NTN Intel Corporation

R1-2005966 Discussion on additional enhancement for NTN ZTE

R1-2006032 discussion on other aspects OPPO

R1-2006147 Remaining issues for NTN Samsung

R1-2006213 Discussion on implicit compatibility to support ATG scenarios in NTN CMCC

R1-2006328 Beam management, PRACH enhancement and polarization for NTN Panasonic

R1-2006381 Considerations on PRACH, CSI and polarization signaling in NTN LG Electronics

R1-2006424 Clarification of NTN assumptions Nokia, Nokia Shanghai Bell

R1-2006466 On other enhancements for NTN Ericsson

R1-2006605 Discussion on the beam management for NTN Beijing Xiaomi Mobile Software

R1-2006620 On feeder link switch InterDigital, Inc.

R1-2006643 Discussion on reference timing delivery for NTN Asia Pacific Telecom co. Ltd

R1-2006678 Other RAN1 aspects for NR NTN THALES

R1-2006807 SSB arrangements, BWP operation and other issues for NTN Qualcomm Incorporated

R1-2006858 Discussion on beam management of NTN CAICT

[102-e-NR-NTN-Other-Enh] – Gilles (MediaTek)

Email discussion/approval on other enhancements including list of topics to specify if beneficial and needed until 8/20; address any remaining aspects by 8/26

R1-2007002 Summary of AI 8.4.4 on Others Aspects of NR NTN Moderator (MediaTek)

R1-2007060 Summary#2 of AI 8.4.4 on Others Aspects of NR NTN Moderator (MediaTek)

R1-2007152 Summary#3 of AI 8.4.4 on Others Aspects of NR NTN Moderator (MediaTek)

R1-2007233 Summary#4 of AI 8.4.4 on Others Aspects of NR NTN Moderator (MediaTek)

Agreement:

One-beam per cell and multiple-beam per cell are supported in existing NR specifications and are baseline for NR NTN.

FFS: The need for potential enhancement for beam management
FFS: The need for potential enhancement on association of SSBs, beams and BWPs

Agreement:

Potential enhancements for support of polarisation signalling in NR NTN can consider at least the following:

· Configuration of DL and UL transmit polarization including Right hand and Left hand circular polarizations (RHCP, LHCP)

· Network broadcast DL and UL transmit polarization configuration

· UE polarization capability (RHCP, LHCP, Linear)

· Dependence of polarisation signaling on deployment scenarios. For example,

o Resource reuse mode with/without polarization for the beam management enhancement

o Fixed polarization per cell/beam for polarization reuse and circular polarisation with intra-UE and inter-UE multiplexing (intra-UE and inter-UE) signalling

RAN1#103-e

8.4 Solutions for NR to support non-terrestrial networks (NTN)

Please refer to RP-201256 for detailed scope of the WI

R1-2009834 Session notes for 8.4 (Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Ericsson)

R1-2009051 NR_NTN_solutions work plan THALES

R1-2009061 Support of smart phones in NTN Thales, ESA, Firstnet, Fraunhofer IIS, Fraunhofer HHI, Qualcomm, Reliance Jio, Intelsat, Hughes Network Systems

· Proposal 1: RAN1 to discuss and endorse the following UE characteristics for the normative phase in addition to the already considered UE characteristics of TR 38.821

Characteristics	Handheld Type 2 (smart phones)
Frequency band	S band (i.e. 2GHz)
Antenna type and configuration	1 Tx and 2 Rx with omni-directional antenna elements with possible transmit antenna switching/selection
Polarisation	Linear
Rx Antenna gain	[-5] dBi per element
Antenna temperature	290 K
Noise figure	7 dB
Tx transmit power	200 mW (23 dBm)
Tx antenna gain	[-5] dBi per element

· Proposal 2: RAN1 to consider UL coverage enhancements to support handheld devices including smart phones in Rel-17 with the following objective

o At least support the connection of smart phones to satellites at orbit up to 1200 km and minimal elevation angle 30 degree or lower.

Decision: The document is noted.

8.4.1 Timing relationship enhancements

R1-2009057 Timing relationship enhancements in NTN Asia Pacific Telecom co. Ltd

R1-2007569 Discussion on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2007660 Discussion on timing relationship enhancements for NR-NTN vivo

R1-2007854 Timing relationship discussion for NTN CATT

R1-2007991 Discussion on timing relationship enhancements for NR NTN China Telecom

R1-2008010 Discussion on timing relationship enhancements for NTN CMCC

R1-2008164 Timing relationship enhancements for NTN Samsung

R1-2008253 Discusson on timing relationship enhancement OPPO

R1-2008359 Calculation of timing relationship offsets Sony

R1-2008410 Discussions on timing relationship enhancements in NTN LG Electronics

R1-2008465 Timing Relationship Enhancement in NTN Apple

R1-2008722 Discussion on timing relationship enhancements for NTN Fraunhofer IIS, Fraunhofer HHI

R1-2008808 Timing relationship enhancements for NR-NTN MediaTek Inc., Eutelsat

R1-2008850 Discussion on timing relationship for NTN ZTE

R1-2008922 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2008989 On timing relationship enhancements for NTN Intel Corporation

R1-2009015 Discussion on timing relationship enhancement for NTN ETRI

R1-2009032 Discussion on the timing relationship enhancement for NTN Xiaomi

R1-2009049 Timing relationship enhancement for NTN Panasonic Corporation

R1-2009076 Timing relationship enhancements to support NTN CAICT

R1-2009091 On timing relationship enhancements for NTN Ericsson

R1-2009116 On timing relationship for NTN InterDigital, Inc.

R1-2009152 Consideration on timing relationship enhancements Spreadtrum Communications

R1-2009186 Discussion on timing relationship enhancements for NTN NTT DOCOMO, INC.

R1-2009242 Views on DL-UL timing relationship for NTN operation Nokia, Nokia Shanghai Bell

R1-2009262 Enhancements on Timing Relationship for NTN Qualcomm Incorporated

[103-e-NR-NTN-Timing-Rel-Enh] – Xingqin (Ericsson)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on 11/5, 11/10, 11/12

R1-2009373 Feature lead summary#1 on timing relationship enhancements Moderator (Ericsson)

R1-2009498 Feature lead summary#2 on timing relationship enhancements Moderator (Ericsson)

R1-2009603 Feature lead summary#3 on timing relationship enhancements Moderator (Ericsson)

R1-2009733 Feature lead summary#4 on timing relationship enhancements Moderator (Ericsson)

Decision from GTW session on 11/04,

Agreement:

Introduce K_offset (may or may not be the same as the K_offset value in other timing relationships) to enhance the timing relationship of HARQ-ACK on PUCCH to MsgB.

Decision from GTW session on 11/11,

Agreement:

· For K_offset configured in system information and used in initial access, at least a cell specific K_offset configuration, which is used in all beams of a cell, should be supported.

· FFS: Beam specific K_offset configured in system information and used in initial access.

Working Assumption:

K_offset can be applied to indicate the first transmission opportunity of PUSCH in Configured Grant Type 2 in the same way as K_offset is applied to the transmission timing of DCI scheduled PUSCH.

Conclusion:

The agreement made at RAN1#102-e about introducing K_offset in the transmission timing of RAR grant scheduled PUSCH is also applicable to fallbackRAR scheduled PUSCH.

Decision: As per email decision posted on Nov.13^th,

Agreement:

Denote by K_mac a scheduling offset other than K_offset:

· If downlink and uplink frame timing are aligned at gNB:

o For UE action and assumption on downlink configuration indicated by a MAC-CE command in PDSCH, K_mac is not needed.

o For UE action and assumption on uplink configuration indicated by a MAC-CE command in PDSCH, K_mac is not needed.

· If downlink and uplink frame timing are not aligned at gNB:

o For UE action and assumption on downlink configuration indicated by a MAC-CE command in PDSCH, K_mac is needed.

o For UE action and assumption on uplink configuration indicated by a MAC-CE command in PDSCH, K_mac is not needed.

· Note: This does not preclude identifying exceptional MAC CE timing relationship(s) that may or may not require K_mac.

8.4.2 Enhancements on UL time and frequency synchronization

R1-2008809 UL Time and Frequency Synchronisation for NR-NTN MediaTek Inc., Eutelsat

· Proposal 1: The target requirements to achieve for UE uplink pre-compensation assuming access link is in S band are:

o Timing error at the satellite < ± 50 µs

o Frequency error at the satellite < ±0.02 ppm or ± 40 Hz at f_c = 2 GHz

It is assumed that gNB does pre-compensation and post-compensation of Doppler shift over the feeder link. For access link in other bands, the proposal above can be readily applied with Frequency error at the satellite < ±0.02 ppm of carrier frequency in these bands.

· Proposal 2: The base Station broadcast Position/ Velocity and implicit Time in each beam in the satellite cell:

o Satellite location/velocity in ECEF coordinates

o Validity Time is the end of SFN where SIB was transmitted (from the satellite)

· Proposal 3: Satellite Position and Velocity information field sizes broadcast on SIB with periodicity X

o The field size for position is 84 bits

o The field size for velocity is 60 bits

o Value of X – e.g. 200 ms, 500 ms, 1000 ms, 1500 ms, 2000 ms

· Proposal 4: for UE with Autonomous acquisition of the TA, UE shall use TA_offset of half the cyclic prefix of PRACH preamble when applying the TA pre-compensation.

· Proposal 5: The connected UE can autonomously adjust the TA to compensate the impact of the timing drift within specified maximum transmission timing error ±T_e = ± 0.39 μs corresponding to a position error of ±117 m.

· Proposal 6: The connected UE can autonomously predict and pre-compensate the Doppler shift drift before transmitting on the UL.

· Proposal 7: In case the gNB pre-compensate the common Doppler shift on the access link w.r.t. center of the beam, the beam-specific common Doppler shift value is broadcast on the NTN SIB for moving beam.

· Proposal 8: In case the gNB pre-compensate the common Doppler shift on the access link w.r.t. center of the beam, the beam-specific ECEF co-ordinates of a fixed Reference Point (RP) corresponding to the beam centre is broadcast on the NTN SIB for earth-fixed beam.

Decision: The document is noted.

R1-2007570 Discussion on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2007661 Discussion on UL time and frequency synchronization enhancements for NR-NTN vivo

R1-2007855 UL time and frequency compensation for NTN CATT

R1-2008011 Enhancements on uplink timing advance for NTN CMCC

R1-2008165 Enhancements on UL time and frequency synchronization for NTN Samsung

R1-2008254 Discussion on UL time and frequency synchronization OPPO

R1-2008360 Enhancement for UL time synchronization Sony

R1-2008411 Discussions on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2008466 Uplink Time and Frequency Synchronization for NTN Apple

R1-2008851 Discussion on UL synchronization for NTN ZTE

R1-2008867 Satellite Position Accuracy Eutelsat S.A.

R1-2008923 Discussion on NTN TA indication Lenovo, Motorola Mobility

R1-2008990 On UL time and frequency synchronization for NTN Intel Corporation

R1-2009016 Discussion on UL timing synchronization for NTN ETRI

R1-2009033 Discussion on UL time and frequency synchronization for NTN Xiaomi

R1-2009058 UL time and frequency synchronization in NTN Asia Pacific Telecom co. Ltd

R1-2009075 Discussion on UL time synchronization acquisition Mitsubishi Electric RCE

R1-2009077 Considerations on Enhancements on UL Time Synchronization in NTN CAICT

R1-2009092 On UL time and frequency synchronization enhancements for NTN Ericsson

R1-2009097 NTN UL time frequency PANASONIC R&D Center Germany

R1-2009117 On UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2009153 Consideration on enhancements on UL time and frequency synchronization Spreadtrum Communications

R1-2009243 Discussion on time and frequency synchronization for NTN systems Nokia, Nokia Shanghai Bell

R1-2009263 UL time and frequency synchronization for NTN Qualcomm Incorporated

R1-2009292 UL time synchronization for NTN systems CEWiT

R1-2009298 Considerations on UL timing and frequency synchronization THALES

[103-e-NR-NTN-UL-Time-Freq-Sync-Enh] – Baptiste (Thales)

Email discussion/approval on UL time and frequency synchronization with checkpoints for agreements on 11/5, 11/10, 11/12

R1-2009485 Feature lead summary on enhancements on UL timing and frequency synchronization Moderator (Thales)

R1-2009556 Feature lead summary#2 on enhancements on UL timing and frequency synchronization Moderator (Thales)

R1-2009672 Feature lead summary#3 on enhancements on UL timing and frequency synchronization Moderator (Thales)

R1-2009697 Feature lead summary#4 on enhancements on UL timing and frequency synchronization Moderator (Thales)

Decision: From GTW session,

Agreement:

An NTN UE in RRC_IDLE and RRC_INACTIVE states is required to at least support UE specific TA calculation based at least on its GNSS-acquired position and the serving satellite ephemeris.

Agreement:

An NR NTN UE in RRC_IDLE and RRC_INACTIVE states shall be capable of at least using its acquired GNSS position and satellite ephemeris to calculate frequency pre-compensation to counter shift the Doppler experienced on the service link.

Final summary in

R1-2009748 Feature lead summary#5 on enhancements on UL timing and frequency synchronization Moderator (Thales)

Decision: As per email decision posted on Nov.13^th,

Agreement:

In NTN, the network may broadcast

A common timing offset value

FFS details of the common timing offset

FFS: A common timing drift rate

Before Msg1/MsgA transmission, the NR NTN UE in idle/inactive mode calculates its TA as follows:

where:

is derived from the User specific TA self-estimation

is derived at least from the common timing offset value if broadcasted by the network. The granularity of and whether is indicated as a Timing Advance or as a Timing Offset value [unit] are FFS. Upon resolving the FFS, one of the X in the equation will be removed.

depends on band and LTE/NR coexistence and is specified in TS 38.213 section 4.2.

is specified in TS 38.211 section 4.1.

Note: UE will not assume that the RTT between UE and gNB is equal to the calculated TA for Msg1/Msg A.

Working assumption:

It is assumed that the requirement on UL time pre-compensation for Msg1/MsgA transmission of an NR NTN UE in idle/inactive mode will be defined such that the existing TAC 12-bit field in msg2 (or msgB) can be reused without any extension.

Agreement:

An NR NTN UE in RRC_CONNECTED states shall be capable of at least using its acquired GNSS position and satellite ephemeris to perform frequency pre-compensation to counter shift the Doppler experienced on the service link.

8.4.3 Enhancements on HARQ

R1-2007856 HARQ operation enhancement for NTN CATT

· At most 32 HARQ processes can be supported without UE capability report if only single layer transmission is assumed in NTN.

· Specify supported HARQ process number for fallback case.

· Re-interprete DCI field to indicate 32 HARQ indexes.

· Keep at least one HARQ process with feedback if UE specific disabling is configured.

· A unified solution of configuration parameter is preferred for with and without HARQ .

· Support more than 8 repetitions in slot-aggreation transmission.

· No optimization is needed for type 1 HARQ-ACK codebook and no touch on type 3 HARQ-ACK codebook.

· Type 2 HARQ-ACK codebook can be optimized for NTN from saving overhead perspective.

· Blind retransmission is not supported in NTN case.

· Slot aggregation factor can be extended to 16 for very low SINR case.

· Support time interleaved slot aggregation to improve transmission reliability.

· No need to define a minimum time gap for without HARQ-ACK feedback case if blind retransmission is not supported.

Decision: The document is noted.

R1-2007571 Discussion on HARQ enhancement for NTN Huawei, HiSilicon

R1-2007662 Discussion on HARQ enhancements for NR-NTN vivo

R1-2008012 Enhancements on HARQ for NTN CMCC

R1-2008166 Enhancements on HARQ for NTN Samsung

R1-2008255 Discussion on HARQ enhancement OPPO

R1-2008256 Discussion on other aspects OPPO

R1-2008361 Enhancements on HARQ for NTN Sony

R1-2008412 Discussions on HARQ enhancements in NTN LG Electronics

R1-2008467 HARQ Enhancements for NTN Apple

R1-2008802 INTELLIGENT PACKET REPETITION IN MOBILE SATELLITE SERVICE (MSS) LINKS TO OVERCOME CHANNEL BLOCKAGES Ligado Networks

R1-2008810 HARQ in NR-NTN MediaTek Inc.

R1-2008852 Discussion on HARQ for NTN ZTE

R1-2008881 Discussion on HARQ for NTN Nomor Research GmbH, Thales

R1-2008924 Enhancements on HARQ for NTN Lenovo, Motorola Mobility

R1-2008991 On HARQ enhancements for NTN Intel Corporation

R1-2009017 Discussion on HARQ Enhancements for NTN ETRI

R1-2009034 Discussion on the HARQ enhancement for NTN Xiaomi

R1-2009050 HARQ enhancement for NTN Panasonic Corporation

R1-2009059 Enhancements on HARQ in NTN Asia Pacific Telecom co. Ltd

R1-2009078 HARQ enhancements to support NTN CAICT

R1-2009093 On HARQ enhancements for NTN Ericsson

R1-2009118 On HARQ enhancement for NTN InterDigital, Inc.

R1-2009154 Consideration on enhancements on HARQ Spreadtrum Communications

R1-2009244 Further discussion on HARQ operation for NTN systems Nokia, Nokia Shanghai Bell

R1-2009264 Enhancements on HARQ for NTN Qualcomm Incorporated

[103-e-NR-NTN-HARQ-Enh] – Nan (ZTE)

Email discussion/approval on HARQ enhancements with checkpoints for agreements on 11/5, 11/10, 11/12

R1-2009420 Summary of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

R1-2009657 Summary#2 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

R1-2009695 Summary#3 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

Decision: From GTW session,

Agreement:

For a DL HARQ process with disabled HARQ feedback, the UE is not expected to receive another PDSCH or set of slot-aggregated PDSCH scheduled for the given HARQ process that starts until [X] after the end of the reception of the last PDSCH or slot-aggregated PDSCH for that HARQ process.

FFS: value of X and units in which it is defined.
FFS: Whether TB of the two PDSCHs needs to be different

Decision: As per email decision posted on Nov.13^th,

Agreement:

Enhanced HARQ process ID indication is supported for DCI 0-2/1-2 and DCI 0-1/1-1 by at least one of following:

Option 1: Slot index as the MSB
Option 1-a:Slot index as the LSB
Option 2: Reusing one bit from other bit field
Option 3: Extending the HARQ process ID field up to 5 bits

FFS: DCI 0-0/1-0
Note: 32 is taken as maximal supported HARQ processes number for both UL and DL

Agreement:

HARQ codebook enhancement is supported as:

For Type-2 HARQ codebook:

Option-1: Reduce codebook size with:

HARQ-ACK codebook only includes HARQ-ACK of PDSCH with feedback-enabled HARQ processes

FFS: the details of C-DAI and T-DAI counting for DCI of PDSCH with feedback-enable/disabled HARQ processes

FFS: at least DCI for SPS release/SPS PDSCH

Option-2: No enhancement
Other options are not precluded.

For Type-1 HARQ codebook, further discuss is needed with down selection among following options:

Option-1: No enhancement;
Option-2: Report NACK on disabled process
Option-3: Reduce codebook size with criteria

FFS: Enhancements for Type-3 HARQ codebook

8.4.44 Other

Including the list of topics to specify if beneficial and needed

R1-2008812 Summary #1 of 8.4.4 Other Aspects of NR-NTN MediaTek Inc.

R1-2007663 Discussion on other aspects for NR-NTN vivo

R1-2007857 Other Aspects of NR-NTN CATT

R1-2008013 Other Aspects for NTN CMCC

R1-2008167 Remaining issues for NTN Samsung

R1-2008319 Discussion on other design aspects for NTN Huawei, HiSilicon

R1-2008362 Discussion on beam management and polarization for NTN Sony

R1-2008413 Discussions on other aspects of NTN LG Electronics

R1-2008468 Other Aspects of NR NTN Apple

R1-2008804 Discussion on the applicability of DFT-S-OFDM for NTN CAICT Withdrawn

R1-2008811 Other Aspects of NR-NTN MediaTek Inc.

R1-2008853 Discussion on additional enhancement for NTN ZTE

R1-2008885 Study Cases and Parameters for System-Level Simulations in NTN WI Nomor Research GmbH, Thales

R1-2008925 Discussion on NTN beam management Lenovo, Motorola Mobility

R1-2009026 SSB, beam management and polarization signaling for NTN Panasonic

R1-2009035 Discussion on the beam management for NTN Xiaomi

R1-2009094 On other enhancements for NTN Ericsson

R1-2009119 On feeder link switch and beam management for NTN InterDigital, Inc.

R1-2009237 Discussion on the applicability of DFT-S-OFDM for NTN CAICT

R1-2009245 Additional aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2009249 Discussion on beam management of NTN CAICT

R1-2009265 BWP operation and other issues for NTN Qualcomm Incorporated

[103-e-NR-NTN-Other-Enh] – Gilles (MediaTek)

Email discussion/approval on other enhancements including list of topics to specify if beneficial and needed with checkpoints for agreements on 11/5, 11/10, 11/12

R1-2009487 Summary #2 of 8.4.4 Other Aspects of NR-NTN MediaTek Inc.

R1-2009736 Summary #4 of 8.4.4 Other Aspects of NR-NTN MediaTek Inc.

Decision: As per email decision posted on Nov.13^th,

Agreement:

Indication of polarization information for DL and UL by the network is supported.

FFS: Signaling details

RAN1#104-e

8.4 Solutions for NR to support non-terrestrial networks (NTN)

Please refer to RP-202908 for detailed scope of the WI

R1-2102193 Session notes for 8.4 (Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Ericsson)

8.4.1 Timing relationship enhancements

R1-2100156 Discusson on timing relationship enhancement OPPO

R1-2100222 Discussion on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2100244 Discussion on timing relationship for NR-NTN ZTE

R1-2100304 Timing relationship enhancements to support NTN CAICT

R1-2100381 Timing relationship enhancement for NTN CATT

R1-2100441 Discussion on timing relationship enhancements for NR-NTN vivo

R1-2100496 Timing relationship enhancements for NTN Zhejiang Lab

R1-2100594 Timing relationship enhancements for NR-NTN MediaTek Inc.

R1-2100654 On timing relationship enhancements for NR NTN Intel Corporation

R1-2100703 Discussions on timing relationship enhancements in NTN LG Electronics

R1-2100757 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2100807 Consideration on timing relationship enhancements Spreadtrum Communications

R1-2100859 Calculation of timing relationship offsets Sony

R1-2100912 Discussion on Timing Relationship Enhancements in NR-NTN China Telecom

R1-2100922 On timing relationship enhancements for NTN Ericsson

R1-2100971 Timing relationship enhancements in NTN Asia Pacific Telecom, FGI, III, ITRI

R1-2100984 On timing relationship for NTN InterDigital, Inc.

R1-2101024 NTN Timing relationship enhancement Panasonic Corporation

R1-2101042 Discussion on timing relationship enhancements for NTN CMCC

R1-2101117 Discussion on the timing relationship enhancement for NTN Xiaomi

R1-2101206 Timing relationship enhancements for NTN Samsung

R1-2101296 Further views on DL-UL timing relationship for NTN operation Nokia, Nokia Shanghai Bell

R1-2101383 Enhancement on Timing Relationship in NTN Apple

R1-2101464 Enhancements on Timing Relationship for NTN Qualcomm Incorporated

R1-2101616 Discussion on timing relationship enhancements for NTN NTT DOCOMO, INC.

R1-2101694 Discussion on Timing Relationship Enhancements for NTN Fraunhofer IIS, Fraunhofer HHI

[104-e-NR-NTN-01] – Xingqin (Ericsson)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on Jan-28, Feb-02, Feb-05

R1-2101793 Feature lead summary#1 on timing relationship enhancements Moderator (Ericsson)

R1-2101904 Feature lead summary#2 on timing relationship enhancements Moderator (Ericsson)

Decision: From GTW session on Jan 29^th,

Agreement:

Confirm the following working assumption:

· K_offset can be applied to indicate the first transmission opportunity of PUSCH in Configured Grant Type 2 in the same way as K_offset is applied to the transmission timing of DCI scheduled PUSCH.

Agreement:

· Update of K_offset after initial access is supported

Agreement:

For unpaired spectrum, extend the value range of K1 from (0..15) to (0..31)

FFS: Whether there is an impact on the size of the PDSCH-to-HARQ_feedback timing indicator field in DCI.

R1-2102019 Feature lead summary#3 on timing relationship enhancements Moderator (Ericsson)

Decision: From GTW session on Feb 2^nd,

Working assumption:

· Introduce K_offset to enhance the adjustment of uplink transmission timing upon the reception of a corresponding timing advance command.

Final summary in R1-2102078.

8.4.2 Enhancements on UL time and frequency synchronization

R1-2100157 Discussion on UL time and frequency synchronization OPPO

R1-2100223 Discussion on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2100245 Discussion on UL synchronization for NR-NTN ZTE

R1-2100305 Considerations on Enhancements on UL Time Synchronization in NTN CAICT

R1-2100382 UL time and frequency compensation for NTN CATT

R1-2100442 Discussion on UL time and frequency synchronization enhancements for NR-NTN vivo

R1-2100520 Considerations on UL timing and frequency synchronization in NR NTN THALES

R1-2100540 UL time synchronization acquisition for NTN Mitsubishi Electric RCE

R1-2100595 UE Time and frequency Synchronisation for NR-NTN MediaTek Inc.

R1-2100655 On UL synchronization for NR NTN Intel Corporation

R1-2100704 Discussions on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2100758 Discussion on NTN uplink time synchronization Lenovo, Motorola Mobility

R1-2100808 Consideration on enhancements on UL time and frequency synchronization Spreadtrum Communications

R1-2100860 Enhancement for UL time synchronization Sony

R1-2100927 On UL time and frequency synchronization enhancements for NTN Ericsson

R1-2100972 UL time and frequency synchronization in NTN Asia Pacific Telecom, FGI

R1-2100985 On UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2101043 Enhancements on UL time and frequency synchronization for NTN CMCC

R1-2101079 Discussion on UL timing synchronization for NTN ETRI

R1-2101118 Discussion on UL time and frequency synchronization for NTN Xiaomi

R1-2101207 Enhancements on UL time and frequency synchronization for NTN Samsung

R1-2101297 Time and frequency synchronization for NTN systems Nokia, Nokia Shanghai Bell

R1-2101384 Discussion on Uplink Time and Frequency Synchronization for NTN Apple

R1-2101465 UL time and frequency synchronization for NTN Qualcomm Incorporated

R1-2101648 Discussion on UL time and frequency synchronization for NTN PANASONIC R&D Center Germany

R1-2101717 UL time synchronization methods for NTN systems CEWiT,IITM,IITH,Tejas Networks,Reliance Jio

[104-e-NR-NTN-02] – Mohamed (Thales)

Email discussion/approval on UL time and frequency synchronization with checkpoints for agreements on Jan-28, Feb-02, Feb-05

R1-2101871 FL Summary#2 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales) (rev of R1-2101805)

Decision: From GTW session on Jan 27^th,

Agreement:

An NTN UE in RRC_CONNECTED state is required to support UE specific TA calculation based at least on its GNSS-acquired position and the serving satellite ephemeris.

· FFS: Operation of closed loop and open loop TA control

Agreement:

For TA update in RRC_CONNECTED state, combination of both open (i.e. UE autonomous TA estimation, and common TA estimation) and closed (i.e., received TA commands) control loops shall be supported for NTN.

· FFS: Details of the combination of open and closed loop TA control

Conclusion:

It is up to RAN4 to decide whether interruptions or measurement gaps are required for GNSS measurements during NTN operation

R1-2102028 FL Summary#4 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales) (rev of R1-2101938)

Decision: From GTW session on Feb 2^nd,

Agreement:

RAN1 should send an LS to RAN4 with the following questions:

Question 1: RAN1 would like to ask RAN4, to indicate what are the NTN UL time synchronization requirements?

For initial access (i.e. PRACH transmission)
For UL transmissions in RRC Connected State

Question 2: RAN1 would like to ask RAN4, to indicate what are the NTN UL frequency synchronization requirements?

For initial access (i.e. PRACH transmission)
For UL transmissions in RRC Connected State

Handling of the LS to RAN4 in [104-e-Post-R17-NTN-01] – Mohamed (Thales)

R1-2102182 FL Summary#6 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

Conclusion:

If DL frequency compensation for the service link Doppler is applied, indication of the amount of frequency compensation is necessary.

FFS: support of DL frequency compensation for the service link Doppler.

Decision: As per email posted on Feb 5^th,

Agreement:

RAN1 to support satellite ephemeris broadcast based at least on one of the following format options:

Option 1: Ephemeris format based on satellite position and velocity state vectors

FFS: Details on state vectors formats
FFS: Details on time reference provisioning/format

Option 2: Ephemeris format based on orbital elements

FFS: Details on orbital elements formats
FFS: Details on time reference provisioning/format

FFS: Whether down-selection is needed or both options are supported

Final summary in R1-2102215.

8.4.3 Enhancements on HARQ

R1-2100158 Discussion on HARQ enhancement OPPO

R1-2100224 Discussion on HARQ enhancement for NTN Huawei, HiSilicon

R1-2100246 Discussion on HARQ for NR-NTN ZTE

R1-2100306 Enhancements on HARQ to support NTN CAICT

R1-2100383 HARQ operation enhancement for NTN CATT

R1-2100443 Discussion on HARQ enhancements for NR-NTN vivo

R1-2100485 INTELLIGENT PACKET REPETITION IN MOBILE SATELLITE SERVICE (MSS) LINKS TO OVERCOME CHANNEL BLOCKAGES Ligado Networks

Late submission

R1-2100491 Discussion on HARQ enhancement for NTN BUPT

R1-2100596 HARQ in NR-NTN MediaTek Inc.

R1-2100656 On HARQ enhancements for NR NTN Intel Corporation

R1-2100705 Discussions on HARQ enhancements in NTN LG Electronics

R1-2100759 Enhancements on HARQ for NTN Lenovo, Motorola Mobility

R1-2100809 Consideration on enhancements on HARQ Spreadtrum Communications

R1-2100861 Enhancements on HARQ for NTN Sony

R1-2100913 Discussion on HARQ Enhancements in NR-NTN China Telecom

R1-2100928 On HARQ enhancements for NTN Ericsson

R1-2100973 Enhancements on HARQ in NTN Asia Pacific Telecom, FGI

R1-2100986 On HARQ enhancement for NTN InterDigital, Inc.

R1-2101025 HARQ enhancement for NTN Panasonic Corporation

R1-2101044 Enhancements on HARQ for NTN CMCC

R1-2101080 Discussion on HARQ Enhancements for NTN ETRI

R1-2101119 Discussion on the HARQ enhancement for NTN Xiaomi

R1-2101208 Enhancements on HARQ for NTN Samsung

R1-2101289 Discussion on HARQ for NTN THALES

R1-2101298 On HARQ operation for NTN systems Nokia, Nokia Shanghai Bell

R1-2101385 Discussion on HARQ Enhancements for NTN Apple

R1-2101466 Enhancements on HARQ for NTN Qualcomm Incorporated

[104-e-NR-NTN-03] – Nan (ZTE)

Email discussion/approval on HARQ enhancements with checkpoints for agreements on Jan-28, Feb-02, Feb-05

R1-2101781 Summary of AI 8.4.3 for HARQ for NTN Moderator (ZTE)

R1-2101903 Summary of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

Decision: From GTW session on Jan 29^th,

Agreement:

For a DL HARQ process with disabled HARQ feedback, the UE is not expected to receive another PDSCH or set of slot-aggregated PDSCH scheduled for the given HARQ process that starts until X after the end of the reception of the last PDSCH or slot-aggregated PDSCH for that HARQ process.

Working assumption: X = T_proc,1
FFS: Whether X should be changed to X = max(T_proc,1, K1) where K1 is the minimum k1 if it is configured, otherwise k1 = 0
Note: The TB of the two PDSCHs can be either same or different

Agreement:

For Type-2 HARQ codebook in NTN: Reduce codebook size with HARQ-ACK codebook only including HARQ-ACK of PDSCH with feedback-enabled HARQ processes

FFS: The details of C-DAI and T-DAI counting for DCI of PDSCH with feedback-enable/disabled HARQ processes

R1-2102055 Summary#3 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

Final summary in R1-2102143.

8.4.44 Other

Including the list of topics to specify if beneficial and needed

R1-2100159 Discussion on other aspects OPPO

R1-2100247 Discussion on additional enhancement for NR-NTN ZTE

R1-2100264 IoT NTN Observations and Proposals Lockheed Martin

R1-2100307 Discusson on beam management of NTN CAICT

R1-2100384 Beam management and other aspects for NTN CATT

R1-2100444 Discussion on other aspects for NR-NTN vivo

R1-2100597 Other Aspects of NR-NTN MediaTek Inc.

R1-2100706 Discussions on other aspects of NTN LG Electronics

R1-2100760 Discussion on other aspects for NTN Lenovo, Motorola Mobility

R1-2100862 Discussion on beam management and polarization for NTN Sony

R1-2100929 On other enhancements for NTN Ericsson

R1-2100974 Scrambling sequence enhancement in NTN Asia Pacific Telecom, FGI, ITRI

R1-2100987 On feeder link switch and beam management for NTN InterDigital, Inc.

R1-2101045 Other Aspects for NTN CMCC

R1-2101120 Discussion on other design aspects for NTN Xiaomi

R1-2101209 Remaining issues for NTN Samsung

R1-2101260 Discussion on other design aspects for NTN Huawei, HiSilicon

R1-2101288 Beam management and BWP operation in NTN THALES

R1-2101295 SSB, beam management and polarization signaling for NTN PANASONIC

R1-2101299 Additional aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2101386 Other Aspects of NR NTN Apple

R1-2101467 BWP operation and other issues for NTN Qualcomm Incorporated

R1-2101693 Discussion on Beam Management for NTN Fraunhofer IIS, Fraunhofer HHI

[104-e-NR-NTN-04] – Hao (Oppo)

Email discussion/approval on other enhancements including list of topics to specify if beneficial and needed with checkpoints for agreements on Jan-28, Feb-02, Feb-05

R1-2101901 Summary #1 of 8.4.4 Other Aspects of NR-NTN Moderator (Oppo)

R1-2102033 Summary #2 of 8.4.4 Other Aspects of NR-NTN Moderator (OPPO)

Decision: From GTW session on Feb 2^nd,

Agreement:

Support at least explicit indication of polarization information for DL by the network

FFS: whether the indication is done by SIB, other RRC signaling, DCI.
FFS: Whether separate signaling is needed for the UL and if so, whether or not a same polarization is indicated for DL and UL

Decision: From GTW session on Feb 4^th,

Conclusion:

Discuss whether or not at least following issues are valid and decide whether or not enhancements are needed in addition to current NR specification for supporting NTN beam management:

· Issue 1: NR BWP is not directly associated with a beam. Thus, when using TCI to change beam from beam 1 to beam 2, it does not trigger NR BWP switching. However, in NTN FRF>1 case, beam switching may result in a BWP switching.

· Issue 2: NR BWP switching in UL and DL are not jointly triggered for FDD. However, in NTN FRF>1 FDD scenario, beam switching may result in a BWP switching in both DL and UL.

· Issue 3: NR dynamic BWP switching requires data scheduling. While in NTN FRF>1 scenario, we may need a fast BWP switching triggering without data scheduling.

· Issue 4: NR BWP switching does not require re-synchronization. However, in NTN FRF>1 scenario, when a satellite beam switching is triggered, UE may need to perform re-synchronization in the switched BWP.

· Issue 5: Since satellite beam switching can be frequent and often highly predictable, mechanisms of configured BWP switching (can be a sequence of BWPs) may be preferred but current NR does not allow it.

· Issue 6: How to deal with BWP switching triggered by bwpInactivityTimer, RA procedure, or simply a need to increase throughput instead of for beam-level mobility.

· Issue 7: NR BWP switching/beam switching is done with UE specific signalling due to UE movement’s. However, in NTN scenario, a satellite BWP/beam switching is common for set of UEs, we may need to a common BWP/beam switching mechanism to save the signalling overhead.

Conclusion:

Discuss the necessity of reporting UE polarization capability considering at least following aspects,

Deployment scenarios.
UE implementation aspects with respect to polarization.
Satellite implementation aspects for switching between polarization states.
Satellite implementation aspects for realizing multiplexing of UEs having different polarization capabilities.

[104-e-NR-NTN-05] – Xiaofeng (Qualcomm)

Email discussion/approval of the reply LS to R1-2100014 until Feb-01

R1-2101952 [Draft] Reply LS on AN-PDB and PER targets for satellite access Qualcomm

Decision: As per email posted on Feb 2^nd, the draft LS is endorsed. Final LS is approved in R1-2102074.

RAN1#104-bis-e

8.4 Solutions for NR to support non-terrestrial networks (NTN)

Please refer to RP-210908 for detailed scope of the WI

R1-2103981 Session notes for 8.4 (Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Ericsson)

R1-2102836 NR_NTN_solutions work plan THALES

8.4.1 Timing relationship enhancements

R1-2102341 Discussion on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2102397 Discussion on timing relationship enhancement OPPO

R1-2102458 Consideration on timing relationship enhancements Spreadtrum Communications

R1-2102572 Timing relationship enhancements to support NTN CAICT

R1-2102633 Timing relationship enhancement for NTN CATT

R1-2102732 Timing relationship enhancements in NTN Asia Pacific Telecom, FGI, ITRI, III

R1-2102751 Timing relationship enhancements for NR-NTN MediaTek Inc.

R1-2102799 Timing relationship enhancements for NTN Zhejiang Lab

R1-2102864 Discussion on Timing Relationship Enhancements in NR-NTN China Telecom

R1-2102873 Timing relationship for NTN Panasonic Corporation

R1-2102884 Discussion on timing relationship enhancements for NTN CMCC

R1-2102914 Discussion on timing relationship for NR-NTN ZTE

R1-2102985 Discussion on the timing relationship enhancement for NTN Xiaomi

R1-2103032 On timing relationship enhancements for NTN Intel Corporation

R1-2103058 On timing relationship enhancements for NTN Ericsson

R1-2103107 Discussion on Timing Relationship Enhancements in NTN Apple

R1-2103168 Enhancements on Timing Relationship for NTN Qualcomm Incorporated

R1-2103241 Timing relationship enhancements for NTN Samsung

R1-2103276 Timing relationship enhancement for NTN InterDigital, Inc.

R1-2103304 Calculation of timing relationship offsets Sony

R1-2103532 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2103578 Discussion on timing relationship enhancements for NTN NTT DOCOMO, INC.

R1-2103619 Discussions on timing relationship enhancements in NTN LG Electronics

R1-2103633 Timing relationship enhancements for NTN ITRI

R1-2103656 Discussion on Timing Relationship Enhancements for NTN Fraunhofer IIS, Fraunhofer HHI

R1-2103669 Discussion on time relations for NTN operation Nokia, Nokia Shanghai Bell

R1-2103671 Discussion on timing relationship enhancement in NTN THALES

R1-2103776 Feature lead summary#1 on timing relationship enhancements Moderator (Ericsson)

[104b-e-NR-NTN-01] – Xingqin (Ericsson)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on Apr-16, Apr-20

R1-2103874 Feature lead summary#2 on timing relationship enhancements Moderator (Ericsson)

R1-2104026 Feature lead summary#4 on timing relationship enhancements Moderator (Ericsson)

Agreement:

For updating K_offset after initial access, at least one of the following options is supported:

Option 1: RRC reconfiguration
Option 2: MAC CE

FFS: Other options

Agreement:

For determination of cell-specific K_offset in system information, down-select one option from below:

Option 1: Signal one offset value for K_offset

Note: For example, the value is expected to cover the RTT of service link plus the RTT between serving satellite and reference point

Option 2: Signal a first offset value and a second offset value. K_offset is equal to the sum of the two offset values

Note: For example, the first offset value is expected to cover the RTT between serving satellite and reference point or is determined by common TA, and the second offset value is expected to cover RTT of service link

Decision: As per email decision posted on April 16^th,

Agreement:

Confirm the following working assumption:

Introduce K_offset to enhance the adjustment of uplink transmission timing upon the reception of a corresponding timing advance command.

Agreement:

When UE is not provided with K_offset value other than the one signaled in system information, the K_offset value signaled in system information is used for all timing relationships that require K_offset enhancement.

Agreement:

UE can be provided by network with a K_mac value.

When UE is not provided by network with a K_mac value, UE assumes K_mac = 0.

Final summary in R1-2104099.

8.4.2 Enhancements on UL time and frequency synchronization

R1-2102342 Discussion on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2102360 Considerations on UL timing and frequency synchronization in NTN THALES

R1-2102398 Discussion on UL time and frequency synchronization OPPO

R1-2102459 Consideration on enhancements on UL time and frequency synchronization Spreadtrum Communications

R1-2102555 Discussion on UL time and frequency synchronization for NTN PANASONIC R&D Center Germany

R1-2102573 Considerations on Enhancements on UL Time Synchronization in NTN CAICT

R1-2102634 UL time and frequency compensation for NTN CATT

R1-2102733 UL time and frequency synchronization in NTN Asia Pacific Telecom, FGI, ITRI, III

R1-2102752 Enhancements on UL Time and Frequency Synchronisation for NR-NTN MediaTek Inc.

R1-2102865 Discussion on UL time and frequency synchronization for NR NTN China Telecom

R1-2102885 Enhancements on UL time and frequency synchronization for NTN CMCC

R1-2102915 Discussion on UL synchronization for NR-NTN ZTE

R1-2102986 Discussion on UL time and frequency synchronization for NTN Xiaomi

R1-2103011 UL time synchronization acquisition for NTN Mitsubishi Electric RCE

R1-2103033 On UL synchronization for NTN Intel Corporation

R1-2103059 On UL time and frequency synchronization enhancements for NTN Ericsson

R1-2103108 On Uplink Time and Frequency Synchronization for NTN Apple

R1-2103169 UL time and frequency synchronization for NTN Qualcomm Incorporated

R1-2103242 Enhancements on UL time and frequency synchronization for NTN Samsung

R1-2103277 UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2103305 Enhancement for UL time synchronization Sony

R1-2103533 Discussion on NTN uplink time synchronization Lenovo, Motorola Mobility

R1-2103544 Discussions on doppler effect in time synchronization for NTN BUPT

R1-2103579 Discussion on UL time synchronization enhancements for NTN NTT DOCOMO, INC.

R1-2103620 Discussions on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2103655 Discussion on UL Time Synchronization for NTN Fraunhofer IIS, Fraunhofer HHI

R1-2103670 Discussion on time and frequency synchronization for NTN operation Nokia, Nokia Shanghai Bell

R1-2103687 On UL time and frequency synchronization enhancements for NR NTN Sequans Communications

R1-2103731 Further discussion on UL time synchronization methods for NTN systems CEWiT, IITM, IITH

R1-2103792 Feature lead summary #1 on enhancements on UL timing and frequency synchronization Moderator (Thales)

[104b-e-NR-NTN-02] – Mohamed (Thales)

Email discussion/approval on UL time and frequency synchronization with checkpoints for agreements on Apr-15, Apr-20

R1-2103905 Feature lead summary #2 on enhancements on UL timing and frequency synchronization Moderator (Thales)

R1-2103989 Feature lead summary #3 on enhancements on UL timing and frequency synchronization Moderator (Thales)

R1-2103990 Feature lead summary #4 on enhancements on UL timing and frequency synchronization Moderator (Thales)

From GTW session

Agreement:

The Timing Advance applied by an NR NTN UE in RRC_IDLE/INACTIVE and RRC_CONNECTED is given by:

Where:

is defined as 0 for PRACH and updated based on TA Command field in msg2/msgB and MAC CE TA command.

FFS: details of N_TA update/accumulation.

is UE self-estimated TA to pre-compensate for the service link delay.
is network-controlled common TA, and may include any timing offset considered necessary by the network.
with value of 0 is supported.

FFS: details of signaling including granularity.

is a fixed offset used to calculate the timing advance.

Note-1: Definition of is different from that in RAN1#103-e agreement.

Note-2: UE might not assume that the RTT between UE and gNB is equal to the calculated TA for Msg1/Msg A.

Note-3: is the common timing offset X as agreed in RAN1 #103-e.

Agreement:

Support serving-satellite ephemeris broadcast based on one or more of the following:

· Set 1: Satellite position and velocity state vectors:

o position X,Y,Z in ECEF (m)

o velocity VX,VY,VZ in ECEF (m/s)

· Set 2: At least the following parameters in orbital parameter ephemeris format:

o Semi-major axis α [m]

o Eccentricity e

o Argument of periapsis ω [rad]

o Longitude of ascending node Ω [rad]

o Inclination i [rad]

o Mean anomaly M [rad] at epoch time t_o

§ FFS: Whether pre-provisioned ephemeris based on orbital elements can be used as reference. Thereby, only delta corrections can be broadcast in order to reduce the overhead

· FFS: The field size for each parameter

· FFS: The impact on signaling due to the required accuracy of serving-satellite ephemeris

· FFS: Whether down-selection is needed or both sets are supported

Conclusion:

The orbital propagator model to be used at UE side can be left to implementation.

Final summary in R1-2104076.

8.4.3 Enhancements on HARQ

Void (not be handled during this e-meeting). No contributions please.

8.4.44 Other

Including the list of topics to specify if beneficial and needed

Void (not be handled during this e-meeting). No contributions please.

The following are withdrawn.

R1-2102477 Discussions on other aspects of NTN BUPT

R1-2103204 Discussions on other aspects of NTN BUPT

RAN1#105-e

8.4 Solutions for NR to support non-terrestrial networks (NTN)

Please refer to RP-210908 for detailed scope of the WI

R1-2106231 Session notes for 8.4 (Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Ericsson)

[105-e-NR-NTN-LS-01] - Xingqin, (Ericsson)

R1-2104155 LS on PDB for new 5QI SA2, Ericsson

Reply LS for email discussion/approval till 5/24.

R1-2106115 Discussion on how to reply to SA2 LS on new 5QI for NTN Moderator (Ericsson)

R1-2106174 DRAFT Reply LS on PDB for new 5QI Moderator (Ericsson)

Decision: The draft LS is endorsed. Final version is approved in R1-2106331.

8.4.1 Timing relationship enhancements

R1-2104255 Discussion on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2104424 Consideration on timing relationship enhancements for NTN Spreadtrum Communications

R1-2104516 Timing relationship enhancement for NTN CATT

R1-2104564 Timing relationship enhancements for NR-NTN MediaTek Inc.

R1-2104607 Discussion on timing relationship enhancements for NTN CMCC

R1-2104667 Enhancements on Timing Relationship for NTN Qualcomm Incorporated

R1-2104708 Timing relationship enhancements for NTN Zhejiang Lab

R1-2104721 Timing relationship enhancements to support NTN CAICT

R1-2104727 On timing relationship enhancements for NTN Ericsson

R1-2105969 Discussion on timing relationship enhancement OPPO (rev of R1-2104770)

R1-2104827 Further discussion of time relation aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2104857 Timing Relationship Enhancements in NR-NTN China Telecom

R1-2104903 On timing relationship enhancements for NTN Intel Corporation

R1-2105101 Timing Relationship Enhancements for NR NTN Apple

R1-2105164 Calculation and application of timing relationship offsets Sony

R1-2105189 Discussion on timing relationship for NR-NTN ZTE

R1-2105207 Discussion on Timing Relationship Enhancements for NTN Fraunhofer IIS, Fraunhofer HHI

R1-2105208 Timing relationship enhancements for NTN ITL

R1-2105306 Timing relationship enhancements for NTN Samsung

R1-2105410 Discussion on timing relationship enhancements for NTN NEC

R1-2105477 Discussions on timing relationship enhancements in NTN LG Electronics

R1-2105559 Discussion on the timing relationship enhancement for NTN Xiaomi

R1-2105619 Timing relationship for NTN Panasonic Corporation

R1-2105623 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2105667 Timing relationship enhancement for NTN InterDigital, Inc.

R1-2105697 Discussion on timing relationship enhancements for NTN NTT DOCOMO, INC.

R1-2105820 Timing relationship enhancements in NTN Asia Pacific Telecom, FGI

[105-e-NR-NTN-01] – Xingqin (Ericsson)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on May 24, May 27

R1-2105974 Feature lead summary#1 on timing relationship enhancements Moderator (Ericsson)

R1-2106059 Feature lead summary#2 on timing relationship enhancements Moderator (Ericsson)

R1-2106114 Feature lead summary#3 on timing relationship enhancements Moderator (Ericsson)

R1-2106254 Feature lead summary#4 on timing relationship enhancements Moderator (Ericsson)

From GTW sessions:

Agreement:

If a UE is provided with a K_mac value, when the UE would transmit a PUCCH with HARQ-ACK information in uplink slot n corresponding to a PDSCH carrying a MAC CE command on a downlink configuration, the UE action and assumption on the downlink configuration shall be applied starting from the first slot that is after slot , where µ is the SCS configuration for the PUCCH.

Note: Here K_mac is assumed to have the unit of the PUCCH slot. This can be revisited after the K_mac signaling design is finalized.

Agreement:

The starts of ra-ResponseWindow and msgB-ResponseWindow are delayed by an estimate of UE-gNB RTT.

· The estimate of UE-gNB RTT is equal to the sum of UE’s TA and K_mac.

Note 1: The UE’s TA is based on the RAN1#104bis-e agreement on Timing Advance applied by an NR NTN UE given by . The estimate of gNB-satellite RTT is equal to the sum of and K_mac. How to treat and can be further discussed.

Note 2: According to the RAN1#104bis-e agreement: When UE is not provided by network with a K_mac value, UE assumes K_mac = 0.

Note 3: The accuracy of the estimated UE-gNB RTT with respect to the true UE-gNB RTT can be further discussed.

Note 4: Other options of determining the estimate of UE-gNB RTT can be further discussed.

Agreement:

The K_offset value signaled in system information is always used for

The transmission timing of RAR / fallbackRAR grant scheduled PUSCH
The transmission timing of Msg3 retransmission scheduled by DCI format 0_0 with CRC scrambled by TC-RNTI
The transmission timing of HARQ-ACK on PUCCH to contention resolution PDSCH scheduled by DCI format 1_0 with CRC scrambled by TC-RNTI

FFS: The transmission timing of HARQ-ACK on PUCCH to contention resolution PDSCH scheduled by DCI format 1_0 with CRC scrambled by C-RNTI

The transmission timing of HARQ-ACK on PUCCH to MsgB scheduled by DCI format 1_0 with CRC scrambled by MsgB-RNTI

FFS: The transmission timing of HARQ-ACK on PUCCH to MsgB scheduled by DCI format 1_0 with CRC scrambled by C-RNTI

FFS: how to treat additional transmission timings related to fallback DCI formats

FFS: how to update this formulation with beam-specific K_offset if beam-specific K_offset is agreed to be supported

Final summary in:

R1-2106325 Feature lead summary#5 on timing relationship enhancements Moderator (Ericsson)

8.4.2 Enhancements on UL time and frequency synchronization

R1-2104256 Discussion on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2106112 Considerations on UL timing and frequency synchronization in NTN THALES (rev of R1-2104301)

R1-2104315 Enhancements on UL time and frequency synchronization PANASONIC R&D Center Germany

R1-2104425 Consideration on enhancements on UL time and frequency synchronization for NTN Spreadtrum Communications

R1-2104517 UL time and frequency synchronization for NTN CATT

R1-2105952 Enhancements on UL Time and Frequency Synchronisation for NR-NTN MediaTek Inc. (rev of R1-2104565)

R1-2104608 Enhancements on UL time and frequency synchronization for NTN CMCC

R1-2104668 UL time and frequency synchronization for NTN Qualcomm Incorporated

R1-2104722 Considerations on Enhancements on UL Time Synchronization in NTN CAICT

R1-2104771 Discussion on UL time and frequency synchronization OPPO

R1-2106142 On UL time and frequency synchronization enhancements for NTN Ericsson (rev of R1-2104811)

R1-2104828 Discussion on time and frequency synchronization for NR over NTN Nokia, Nokia Shanghai Bell

R1-2104904 On UL synchronization for NTN Intel Corporation

R1-2105102 Uplink Time and Frequency Synchronization for NR NT Apple

R1-2105165 Considerations on UL time synchronisation Sony

R1-2105190 Discussion on UL synchronization for NR-NTN ZTE

R1-2105214 Discussion on NTN uplink time synchronization Lenovo, Motorola Mobility

R1-2105272 Discussion on UL Time Synchronization for NTN Fraunhofer IIS, Fraunhofer HHI

R1-2105307 Enhancements on UL time and frequency synchronization for NTN Samsung

R1-2105478 Discussions on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2105560 Discussion on UL time and frequency synchronization for NTN Xiaomi

R1-2105634 Enhancements on frequency synchronization for NTN Sharp

R1-2105668 UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2105698 Discussion on UL time and frequency synchronization enhancements for NTN NTT DOCOMO, INC.

R1-2105812 On satellite pass predictions under NTN discontinuous coverage Sateliot, Gatehouse, ESA, Kepler

R1-2105821 UL time and frequency synchronization in NTN Asia Pacific Telecom, FGI

R1-2105947 UL time synchronization acquisition for NTN Mitsubishi Electric RCE

[105-e-NR-NTN-02] – Mohamed (Thales)

Email discussion/approval on UL time and frequency synchronization with checkpoints for agreements on May 25, May 27

R1-2104302 Feature lead summary #1 on enhancements on UL timing and frequency synchronization for NR NTN THALES

R1-2104303 Feature lead summary #2 on enhancements on UL timing and frequency synchronization for NR NTN THALES

R1-2104304 Feature lead summary #3 on enhancements on UL timing and frequency synchronization for NR NTN THALES

R1-2104305 Feature lead summary #4 on enhancements on UL timing and frequency synchronization for NR NTN THALES

Agreement:

Specifications should support delivery of ephemeris information using both ephemeris formats, i.e., state vectors and orbital elements.

Agreement:

RAN1 should send an LS to SA3, SA1 and possibly SA3-LI to get more inputs regarding the security/regulatory aspects if the NTN GW/gNB position is broadcast or possible to be derived by the UE with assistance information from the network, and on any aspects related to accuracy of the position.

Conclusion:

The Doppler shift over the feeder link and any transponder frequency error for both Downlink and Uplink is compensated by the GW and satellite-payload without any specification impacts in Release 17.

R1-2106305 LS on broadcast of NTN GW or gNB position RAN1, THALES

R1-2106332 LS on broadcast of NTN GW or gNB position RAN1, THALES

Decision: Final LS is approved in R1-2106332 with removal of the sentence, “Such assistance information from the Network might also be used by the UE to derive the position of the NTN GW or the position of gNB.”

Final summary in:

R1-2106290 Feature lead summary #5 on enhancements on UL timing and frequency synchronization for NR NTN THALES

[105-e-NR-NTN-05] - Hao (OPPO)

Email discussion/approval for R1-2104230 from May 21 to May 26

R1-2106186 Summary of Email discussion/approval for R1-2104230 Moderator (OPPO)

R1-2106340 DRAFT Reply LS on TA pre-compensation Moderator (OPPO)

Decision: As per decision posted on May 28^th, the draft LS is endorsed. Final version is approved in R1-2106341.

8.4.3 Enhancements on HARQ

R1-2104257 Discussion on HARQ enhancement for NTN Huawei, HiSilicon

R1-2104357 Discussion on HARQ enhancements for NR-NTN vivo

R1-2104402 Discussion on HARQ for NTN Magister Solutions Ltd

R1-2104426 Consideration on enhancements on HARQ for NTN Spreadtrum Communications

R1-2104518 HARQ operation enhancement for NTN CATT

R1-2104566 Enhancements on HARQ for NR NTN MediaTek Inc.

R1-2104609 Enhancements on HARQ for NTN CMCC

R1-2104669 Enhancements on HARQ for NTN Qualcomm Incorporated

R1-2104723 Enhancements on HARQ to support NTN CAICT

R1-2104772 Discussion on HARQ enhancements OPPO

R1-2104812 On HARQ enhancements for NTN Ericsson

R1-2104829 Further discussion related to HARQ operation for NR over NTN Nokia, Nokia Shanghai Bell

R1-2105054 HARQ enhancements for NTN networks CEWiT

R1-2105103 On HARQ Enhancements for NR NTN Apple

R1-2105166 Enhancement on HARQ for NTN Sony

R1-2105191 Discussion on HARQ for NR-NTN ZTE

R1-2105215 Enhancements on HARQ for NTN Lenovo, Motorola Mobility

R1-2105222 Discussion on HARQ Enhancements for NTN ETRI

R1-2105308 Enhancements on HARQ for NTN Samsung

R1-2105411 Discussion on HARQ enhancements for NR NTN NEC

R1-2105479 Discussions on HARQ enhancements in NTN LG Electronics

R1-2105561 Discussion on the HARQ enhancement for NTN Xiaomi

R1-2105620 HARQ enhancement for NTN Panasonic Corporation

R1-2105669 HARQ enhancement for NTN InterDigital, Inc.

R1-2105757 Enhancements on HARQ for NTN ITRI

R1-2105822 Enhancements on HARQ in NTN Asia Pacific Telecom, FGI

R1-2106013 Summary#1 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

[105-e-NR-NTN-03] – Nan (ZTE)

Email discussion/approval on enhancements on HARQ with checkpoints for agreements on May 24, May 27

R1-2106066 Summary#2 of AI 8.4.3 for HARQ for NTN Moderator (ZTE)

R1-2106171 Summary#3 of AI 8.4.3 for HARQ for NTN Moderator (ZTE)

From GTW sessions:

Agreement:

For enhancement on the HARQ process indication, extend the HARQ process ID field up to 5 bits for DCI 0-2/1-2

Agreement:

For Type-2 HARQ codebook in NTN,

For the DCI of PDSCH with feedback-enabled HARQ processes, the C-DAI and T-DAI are the count of only feedback-enabled processes
FFS: Whether DCI for SPS release and any other DCIs are included in counting of C-DAI and T-DAI

Agreement:

Confirm the previous working assumption for X = T_proc,1 where X is defined from the end of the reception of the last PDSCH or slot-aggregated PDSCH for a given HARQ process with disabled feedback to the start of the PDCCH carrying the DCI scheduling another PDSCH or set of slot-aggregated PDSCH for the given HARQ process.

Agreement:

For enhancement on the HARQ process indication at least for DCI 0-1/1-1, the Option-1 and Option-1a are lower priority for further discussion.

Agreement:

Discussion of enhancement(s) on the aggregated transmission (including repetition) is prioritized to improve the performance in NTN.

Final summary in:

R1-2106269 Summary#4 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

8.4.44 Other

Including the list of topics to specify if beneficial and needed

R1-2104776 FL Summary of 8.4.4 Other Aspects of NR-NTN OPPO

R1-2104307 Beam management and BWP operation in NTN THALES

R1-2104358 Discussion on other aspects for NR-NTN vivo

R1-2104427 Consideration on beam management and other aspects for NTN Spreadtrum Communications

R1-2104519 Beam management and other aspects for NTN CATT

R1-2104610 Other Aspects for NTN CMCC

R1-2104670 BWP operation and other issues for NTN Qualcomm Incorporated

R1-2104773 Discusson on beam management OPPO

R1-2104813 On other enhancements for NTN Ericsson

R1-2104830 Discussion of other aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2105104 Discussions on Other Aspects of NR NTN Apple

R1-2105148 Beam management and polarization signaling for NTN Panasonic

R1-2105167 Discussion on beam management and polarization for NTN Sony

R1-2105192 Discussion on additional enhancement for NR-NTN ZTE

R1-2105209 Discussion on Beam Management for NTN Fraunhofer IIS, Fraunhofer HHI

R1-2105216 Discussion on other aspects for NTN Lenovo, Motorola Mobility

R1-2105223 Discussion on beam management for NTN ETRI

R1-2105309 Remaining issues for NTN Samsung Samsung

R1-2105480 Discussions on other aspects of NTN LG Electronics

R1-2105529 Discussion on other design aspects for NTN Huawei, HiSilicon

R1-2105562 Discussion on other design aspects for NTN Xiaomi

R1-2105671 On beam management for NTN InterDigital, Inc.

[105-e-NR-NTN-04] – Hao (Oppo)

Email discussion/approval on enhancements on other topics with checkpoints for agreements on May 25, May 27

R1-2106175 FL Summary#2 of 8.4.4 Other Aspects of NR-NTN OPPO

R1-2106263 FL Summary#3 of 8.4.4 Other Aspects of NR-NTN OPPO

Agreement:

Same beam layout in BWP#0 and BWP#x (Option 1) and hierarchical beam for BWP#0 (Option 2) should be supported by the specifications for NR-NTN.

FFS: Whether any specification changes are needed specifically to support this functionality

Agreement:

For explicit indication of polarization information for DL by the network, support indication in SIB

FFS: Signaling details for indication in SIB

Agreement:

Polarization information for UL may be indicated in SIB by the network
UE assumes a same polarization for UL and DL, when the UL polarization information is absent.
FFS: Signaling details for indication in SIB

Final summary in:

R1-2106336 Final Summary of 8.4.4 Other Aspects of NR-NTN Moderator (Oppo)

RAN1#106-e

8.4 Solutions for NR to support non-terrestrial networks (NTN)

Please refer to RP-211557 for detailed scope of the WI

R1-2108604 Session notes for 8.4 (Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Ericsson)

R1-2107076 Updated NR_NTN_solutions work plan THALES

8.4.1 Timing relationship enhancements

R1-2106482 Discussion on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2106591 Discussion on timing relationship enhancements for NR-NTN vivo

R1-2106701 Discussion on timing relationship enhancements for NTN Spreadtrum Communications

R1-2106723 Timing relationship enhancements for NTN Zhejiang Lab

R1-2106754 Discussion on timing relationship enhancement for NTN Baicells

R1-2106805 Calculation and application of timing relationship offsets Sony

R1-2106884 Timing relationship enhancements for NTN Samsung

R1-2106967 Further discussion on timing relationship enhancements for NTN CATT

R1-2107014 Discussion on timing relationship enhancements for NTN NEC

R1-2107064 Timing relationship enhancements for NR-NTN MediaTek Inc.

R1-2107167 Timing relationship enhancements to support NTN CAICT

R1-2107194 Discussion on timing relationship enhancements for NTN Hyundai Motors

R1-2107243 Discusson on timing relationship enhancement OPPO

R1-2107287 Timing relationship enhancements in NTN FGI, Asia Pacific Telecom, III, ITRI

R1-2107341 Enhancements on Timing Relationship for NTN Qualcomm Incorporated

R1-2107399 Discussion on timing relationship enhancements for NTN CMCC

R1-2107468 Timing relationship for NTN Panasonic Corporation

R1-2107538 Discussions on timing relationship enhancements in NTN LG Electronics

R1-2107588 On timing relationship enhancements for NTN Intel Corporation

R1-2107636 On timing relationship enhancements for NTN Ericsson

R1-2107736 On Timing Relationship Enhancements for NR NTN Apple

R1-2107775 Discussion on timing relationship for NR-NTN ZTE

R1-2107855 Discussion on timing relationship enhancements for NTN NTT DOCOMO, INC.

R1-2107918 Discussion on the timing relationship enhancement for NTN Xiaomi

R1-2107944 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2107992 Timing relationship enhancements for NTN ITL

R1-2108031 Timing relationship enhancement for NTN InterDigital, Inc.

R1-2108070 Discussion on Timing Relationship Enhancements for NTN Fraunhofer IIS, Fraunhofer HHI

R1-2108090 Time relation aspects for NR over NTN Nokia, Nokia Shanghai Bell

[106-e-NR-NTN-01] – Xingqin (Ericsson)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on August 19, 24 and 27

R1-2108220 Feature lead summary#1 on timing relationship enhancements Moderator (Ericsson)

Agreement:

The UE-specific K_offset can be provided and updated by network with MAC CE.
FFS: UE can be provided and updated by network with a UE-specific K_offset in RRC reconfiguration

FFS: Details on whether and how the two solutions work together

R1-2108331 Feature lead summary#2 on timing relationship enhancements Moderator (Ericsson)

R1-2108439 Feature lead summary#3 on timing relationship enhancements Moderator (Ericsson)

Decision: As per email decision posted on Aug 20^th,

Agreement

The unit of K_offset is number of slots for a given subcarrier spacing.

· FFS: one subcarrier spacing value or different subcarrier spacing values for different scenarios.

Agreement

The information of K_mac is carried in system information.

Agreement

The unit of K_mac is number of slots for a given subcarrier spacing.

· FFS: one subcarrier spacing value or different subcarrier spacing values for different scenarios.

Agreement

In the estimate of UE-gNB RTT, which is equal to the sum of UE’s TA and K_mac, for delaying the starts of ra-ResponseWindow and msgB-ResponseWindow, the UE’s TA is equal to with .

From GTW session:

Agreement:

For defining value range(s) of K_offset, down-select one option from below:

Option 1: One value range of K_offset covering all scenarios.
Option 2: Different value ranges of K_offset for different scenarios.

Decision: As per email decision posted on Aug 26^th,

Agreement

For random access procedure initiated by a PDCCH order received in downlink slot , UE determines the next available PRACH occasion after uplink slot to transmit the ordered PRACH.

Note: The UE’s TA is based on the RAN1#104bis-e agreement on Timing Advance applied by an NR NTN UE given by , where is assumed for PDCCH ordered PRACH.
FFS: Which value of should be applied
FFS: Whether the timing relationship is impacted by UE behavior within or after the validity duration.

Final summary in R1-2108555.

8.4.2 Enhancements on UL time and frequency synchronization

R1-2106483 Discussion on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2106556 Considerations on UL timing and frequency synchronization in NTN THALES

R1-2106592 Discussion on UL time and frequency synchronization enhancements for NR-NTN vivo

R1-2106702 Discussion on enhancements on UL time and frequency synchronization for NTN Spreadtrum Communications

R1-2106755 Discussion on UL time and frequency synchronization enhancement for NTN Baicells

R1-2106806 Considerations on UL time synchronisation Sony

R1-2106885 Enhancements on UL time and frequency synchronization for NTN Samsung

R1-2106968 Enhancements on UL time and frequency synchronization for NTN CATT

R1-2107020 Enhancements on UL time and frequency synchronization PANASONIC R&D Center Germany

R1-2107065 Enhancements on UL Time and Frequency Synchronisation for NR-NTN MediaTek Inc.

R1-2107244 Discussion on UL time and frequency synchronization OPPO

R1-2107288 UL time and frequency synchronization in NTN FGI, Asia Pacific Telecom, III, ITRI

R1-2107342 UL time and frequency synchronization for NTN Qualcomm Incorporated

R1-2107400 Enhancements on UL time and frequency synchronization for NTN CMCC

R1-2107539 Discussions on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2107589 On UL synchronization for NTN Intel Corporation

R1-2108240 On UL time and frequency synchronization enhancements for NTN Ericsson (rev of R1-2107637)

R1-2107737 On Uplink Time and Frequency Synchronization for NR NTN Apple

R1-2107776 Discussion on UL synchronization for NR-NTN ZTE

R1-2107856 Discussion on UL time synchronization enhancements for NTN NTT DOCOMO, INC.

R1-2107890 Considerations on Enhancements on UL Time Synchronization in NTN CAICT

R1-2107919 Discussion on UL time and frequency synchronization for NTN Xiaomi

R1-2107945 Discussion on NTN uplink time synchronization Lenovo, Motorola Mobility

R1-2108032 UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2108073 Discussion on UL Time Synchronization for NTN Fraunhofer IIS, Fraunhofer HHI

R1-2108091 Time and frequency synchronization for NR over NTN Nokia, Nokia Shanghai Bell

[106-e-NR-NTN-02] – Mohamed (Thales)

Email discussion/approval on UL time and frequency synchronization with checkpoints for agreements on August 19, 24 and 27

R1-2106781 Feature lead summary #1 on enhancements on UL timing and frequency synchronization THALES

R1-2106782 Feature lead summary #2 on enhancements on UL timing and frequency synchronization THALES

From GTW session:

Agreement:

A validity duration configured by the network for satellite ephemeris data indicates the maximum time during which the UE can apply the satellite ephemeris without having acquired new satellite ephemeris.

FFS: Associated UE behaviour if the UE does not read the ephemeris within the validity duration.

FFS: Whether the same validity duration can be applied for Common TA.

Conclusion:

Indication of common post-compensation frequency offset for Uplink is not needed.

Agreement:

Confirm the working assumption on non-extension of TAC 12-bit field in msg2 (or msgB) and that the UE follows the requirements on UL time pre-compensation for Msg1/MsgA transmission as defined by RAN4.

R1-2106784 Feature lead summary #4 on enhancements on UL timing and frequency synchronization THALES

R1-2106785 Feature lead summary #5 on enhancements on UL timing and frequency synchronization THALES

From GTW session:

Agreement:

Serving satellite ephemeris Epoch time is implicitly known as a reference time defined by the starting time of a DL slot and/or frame.

· FFS: Whether this starting time is given by predefined rule or it is indicated by the Network

Agreement:

In NTN, to avoid that the UE over pre-compensates its TA during RACH procedure, down-select one option from below:

· Option 1: PRACH transmission is delayed by

· Option 2: TA margin can be considered and it is explicitly indicated to the UE

· Option 3: TA margin can be considered and it is included within the Common TA

· Option 4: UE handles it via implementation

R1-2108586 FL Summary #6 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From GTW session:

Agreement:

· In NR NTN, N_TA update based on TA Command field in msg2/msgB and MAC CE TA command is used for UL timing alignment correction as follows:

o When TAC ( in msg2/msgB is received, UE receives the first adjustment and is updated as follows:

§ , FFS: the value of ,

o When TACs ( provided within the MAC CE is received, is updated as follows:

§ ,

Decision: As per email decision posted on Aug 31^st,

Working assumption:

Common TA may include parameter(s) indicating timing drift.

The UE will apply common TA according to the parameters provided by the network (if any). No offset between the common TA according to the parameters provided by the network and the actual feeder link RTT is considered when defining UE UL timing error requirements.

Final summary in R1-2108587.

[106-e-NR-NTN-05] - Hao (OPPO)

Email discussion/approval for LS on TA pre-compensation in R1-2104230 (from AI5) until August 24

R1-2108409 DRAFT Reply LS on TA pre-compensation OPPO

R1-2108518 Draft reply LS on TA pre-compensation Moderator (OPPO)

Decision: The draft LS is endorsed. Final version is approved in R1-2108410.

8.4.3 Enhancements on HARQ

R1-2106484 Discussion on HARQ enhancement for NTN Huawei, HiSilicon

R1-2106593 Discussion on HARQ enhancements for NR-NTN vivo

R1-2106703 Discussion on enhancements on HARQ for NTN Spreadtrum Communications

R1-2106756 Discussion on HARQ enhancement for NTN Baicells

R1-2106807 Enhancements on HARQ for NTN Sony

R1-2106886 Enhancements on HARQ for NTN Samsung

R1-2106969 HARQ operation enhancement for NTN CATT

R1-2107015 Discussion on HARQ enhancements for NR NTN NEC

R1-2107066 Enhancements on HARQ for NR NTN MediaTek Inc.

R1-2107168 Enhancements on HARQ to support NTN CAICT

R1-2107245 Discussion on HARQ enhancements OPPO

R1-2107289 Enhancements on HARQ in NTN FGI, Asia Pacific Telecom, III, ITRI

R1-2107343 Enhancements on HARQ for NTN Qualcomm Incorporated

R1-2107401 Enhancements on HARQ for NTN CMCC

R1-2107469 HARQ enhancement for NTN Panasonic Corporation

R1-2107475 Discussion on HARQ Enhancements for NTN ETRI

R1-2107540 Discussions on HARQ enhancements in NTN LG Electronics

R1-2107638 On HARQ enhancements for NTN Ericsson

R1-2107738 HARQ Enhancements for NR NTN Apple

R1-2107777 Discussion on HARQ for NR-NTN ZTE

R1-2107857 Discussion on HARQ enhancements for NR NTN NTT DOCOMO, INC.

R1-2107920 Discussion on the HARQ enhancement for NTN Xiaomi

R1-2107993 Discussion on HARQ enhancements for NTN ITL

R1-2108033 HARQ enhancement for NTN InterDigital, Inc.

R1-2108092 Remaining HARQ aspects of NR over NTN Nokia, Nokia Shanghai Bell

[106-e-NR-NTN-03] – Nan (ZTE)

Email discussion/approval on HARQ enhancements with checkpoints for agreements on August 19, 24 and 27

R1-2108343 Summary#1 of AI 8.4.3 for HARQ in NTN Moderator(ZTE)

From GTW session:

Agreement:

For enhancement on the HARQ process indication, extend the HARQ process ID field up to 5 bits for DCI 0-1/1-1 when the maximum supported HARQ processes number is configured as 32.

Agreement:

For Type-1 HARQ codebook, if DCIs carrying the feedback-disabled and feedback-enabled HARQ processes are detected by UE, one of following options should be supported:

Option-1: The UE will report NACK only for the feedback-disabled HARQ process regardless of decoding results of corresponding PDSCH
Option-2: The UE will report NACK/ACK for the feedback-disabled HARQ process depending on the decoding results of corresponding PDSCH

FFS: Other cases, e.g., if only DCI carrying feedback-disabled HARQ process is detected by UE

R1-2108511 Summary#2 of AI 8.4.3 for HARQ in NTN Moderator(ZTE)

Decision: As per email decision posted on Aug 25^th,

Agreement:

For enhancement on the HARQ process indication, one of following options for DCI 0-0/1-0 can be considered:

Option 2: Reusing one bit from other bit field
Option 4: No enhancement

Agreement:

For Type-1 HARQ codebook, if only DCI carrying feedback-disabled HARQ process is detected by UE, one of following options should be supported:

Option-1: The UE’s behavior is same as the case if DCIs carrying the feedback-disabled and feedback-enabled HARQ processes are detected by UE
Option-2: The UE should skip the codebook feedback at least when the feedback is carried by PUCCH

FFS: the case that feedback is carried by PUSCH.

Agreement:

The maximum number of supported aggregation factor (i.e., pdsch-AggregationFactor) for DL PDSCH is [X]

FFS: X = 8, 16 or 32

From GTW session:

Agreement:

For the DCI of PDSCH with feedback-disabled HARQ processes, only one of following is supported for Type-2 codebook:

Option-1: The C-DAI and T-DAI are the count of feedback-enabled processes, despite they are not incremented, and are taken into account by the UE for type 2 codebook generation.
Option-2: The C-DAI and T-DAI are ignored by the UE regardless of the value for Type 2 codebook generation.

8.4.44 Other

Including the list of topics to specify if beneficial and needed

R1-2106594 Discussion on other aspects for NR-NTN vivo

R1-2106704 Discussion on beam management and other aspects for NTN Spreadtrum Communications

R1-2106757 Discussion on beam management and other consideration for NTN Baicells

R1-2106808 Discussion on beam management and polarization for NTN Sony

R1-2106887 Remaining issues for NTN Samsung Samsung

R1-2106970 Beam management and other aspects for NTN CATT

R1-2106999 Discussion on channel models for marine and inland river scenes GDCNI

R1-2107016 Remaining issues for NR NTN NEC

R1-2107246 Discusson on beam management OPPO

R1-2107290 Other aspects of NR-NTN FGI, Asia Pacific Telecom, III, ITRI

R1-2107344 BWP operation and other issues for NTN Qualcomm Incorporated

R1-2107381 Problems of Rel-17 NTN WI from HAPS point of view SoftBank Corp.

R1-2107402 Other Aspects for NTN CMCC

R1-2107463 Beam management and polarization signaling for NTN Panasonic

R1-2107541 Discussions on other aspects of NTN LG Electronics

R1-2107644 On other enhancements for NTN Ericsson

R1-2107675 Discussion on other design aspects for NTN Huawei, HiSilicon

R1-2107739 On Other Aspects of NR NTN Apple

R1-2107778 Discussion on additional enhancement for NR-NTN ZTE

R1-2107921 Discussion on other design aspects for NTN Xiaomi

R1-2107946 Discussion on other aspects for NTN Lenovo, Motorola Mobility

R1-2108034 On beam management for NTN InterDigital, Inc.

R1-2108093 Further discussion of other aspects for NR over NTN Nokia, Nokia Shanghai Bell

[106-e-NR-NTN-04] – Hao (OPPO)

Email discussion/approval on other enhancements including list of topics to specify if beneficial and needed with checkpoints for agreements on August 19, 24 and 27

R1-2108234 Summary #1 of 8.4.4 Other Aspects of NR-NTN Moderator (OPPO)

From GTW session:

Agreement:

When polarization signalling is present in SIB

SIB indicates DL and/or UL polarization information using respective polarization type parameters to indicate: RHCP or LHCP or linear
FFS: whether polarization signalling is per SSB

R1-2108411 Summary #2 of 8.4.4 Other Aspects of NR-NTN Moderator (OPPO)

R1-2108517 Summary #3 of 8.4.4 Other Aspects of NR-NTN Moderator (OPPO)

No more convergence could be achieved during this meeting.

RAN1#106-bis-e

8.4 Solutions for NR to support non-terrestrial networks (NTN)

Please refer to RP-211557 for detailed scope of the WI.

Incoming LS(s) related to this work/study item under agenda item 5: R1-2108699, R1-2108705.

R1-2110613 Session notes for 8.4 (Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Ericsson)

R1-2110374 Updated NR_NTN_solutions work plan Thales

R1-2110685 3GPP TSG-RAN WG1 Agreements under 8.4 up to eMeeting RAN1#106-bis-e WI rapporteur (Thales)

[106bis-e-R17-RRC-NR-NTN] – Mohamed (Thales)

Email discussion on Rel-17 RRC parameters for NR to support NTN

- 1^st check point: October 14

- Final check point: October 19

R1-2110624 Summary of [106bis-e-R17-RRC-NR-NTN] Email discussion on Rel-17 RRC parameters for NR to support NTN Moderator (Thales)

Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].

8.4.1 Timing relationship enhancements

R1-2108747 Discussion on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2108909 Discussion on timing relationship enhancements for NTN Spreadtrum Communications

R1-2108971 Discussion on timing relationship enhancements for NR-NTN vivo

R1-2109025 Timing relationship enhancements for NTN Zhejiang Lab

R1-2109076 Discussion on timing relationship enhancement OPPO

R1-2109164 Further discussion on timing relation aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2109168 Timing relationship enhancements for NR-NTN MediaTek Inc.

R1-2109220 Further discussion on timing relationship enhancements for NTN CATT

R1-2109279 Discussion on timing relationship enhancements for NTN CMCC

R1-2109323 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2109343 Timing relationship enhancements to support NTN CAICT

R1-2109357 Discussion on timing relationship enhancements for NTN NEC

R1-2109409 Discussion on the timing relationship enhancement for NTN Xiaomi

R1-2109486 Timing relationship enhancements for NTN Samsung

R1-2109609 On timing relationship enhancements for NTN Intel Corporation

R1-2109675 Discussion on timing relationship enhancements for NTN NTT DOCOMO, INC.

R1-2109763 Discussion on timing relationship enhancement for NTN Baicells

R1-2109786 Calculation and application of timing relationship offsets Sony

R1-2109825 Timing relationship enhancements in NTN FGI, Asia Pacific Telecom, III

R1-2109843 Discussion on timing relationship for NR-NTN ZTE

R1-2109865 Timing relationship for NTN Panasonic Corporation

R1-2109878 Timing relationship enhancement for NTN InterDigital, Inc.

R1-2109927 On timing relationship enhancements for NTN Ericsson

R1-2109932 Timing relationship enhancements for NTN ITL

R1-2110031 Discussion on Timing Relationship Enhancements for NR NTN Apple

R1-2110084 Discussions on timing relationship enhancements in NTN LG Electronics

R1-2110183 Enhancements for Timing Relationship for NTN Qualcomm Incorporated

R1-2110290 Discussion on Timing Relationship Enhancements for NTN Fraunhofer IIS - Fraunhofer HHI

[106bis-e-NR-NTN-01] – Xingqin (Ericsson)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on October 14 and 19

R1-2110387 Feature lead summary#1 on timing relationship enhancements Moderator (Ericsson)

From Oct 11^th GTW session

Agreement:

Signalling one value for cell-specific K_offset is supported.

R1-2110487 Feature lead summary#2 on timing relationship enhancements Moderator (Ericsson)

R1-2110505 Feature lead summary#3 on timing relationship enhancements Moderator (Ericsson)

From Oct 15^th GTW session

Agreement:

· For the reference subcarrier spacing value for the unit of K_offset in FR1, a value of 15 kHz is used.

· FFS: FR2

Agreement:

The granularity of the reported TA is slot.

· FFS how to round TA value to slot level granularity

R1-2110541 Feature lead summary#4 on timing relationship enhancements Moderator (Ericsson)

From Oct 18^th GTW session

Agreement:

For the reference subcarrier spacing value for the unit of K_mac in FR1, a value of 15 kHz is used.

· FFS: FR2

Agreement:

For defining value range(s) of K_offset, down-select one option from below:

Option	Value range	Step size
Option 1: One value range of K_offset covering all scenarios.	[0] – [542] ms	Same as the unit of K_offset
Option 2: Different value ranges of K_offset for different scenarios.	LEO: [0] – [49] ms MEO: [93] – [395] ms GEO: [477] – [542] ms FFS: ATG and HAPS FFS: How to determine the scenarios	Same as the unit of K_offset
Note: If deemed necessary, numbers in bracket can be further updated at RAN1#107-e.

Agreement:

For defining value range(s) of K_mac, down-select one option from below:

Option	Value range	Step size
Option 1: One value range of K_mac covering all scenarios.	[1] – [271] ms	Same as the unit of K_mac
Option 2: Different value ranges of K_mac for different scenarios.	LEO: [1] – [25] ms MEO: [1] – [198] ms GEO: [1] – [271] ms FFS: ATG and HAPS FFS: How to determine the scenarios	Same as the unit of K_mac
Note 1: If deemed necessary, numbers in bracket can be further updated at RAN1#107-e. Note 2: Note that it was agreed already that when UE is not provided by network with a K_mac value, UE assumes K_mac = 0.

Decision: As per email decision posted on Oct 20^th,

Agreement:

RAN1 to conclude the following as a basis to reply to RAN2:

· RAN1 definition of UE’s TA is given by the following agreement:

Agreement:

The Timing Advance applied by an NR NTN UE in RRC_IDLE/INACTIVE and RRC_CONNECTED is given by:

Where:

§ is defined as 0 for PRACH and updated based on TA Command field in msg2/msgB and MAC CE TA command.

· FFS: details of N_TAupdate/accumulation.

§ is UE self-estimated TA to pre-compensate for the service link delay.

§ is network-controlled common TA, and may include any timing offset considered necessary by the network.

§ with value of 0 is supported.

· FFS: details of signaling including granularity.

§ is a fixed offset used to calculate the timing advance.

· In addition, RAN1 has agreed the following for UE TA reporting:

Agreement:

The granularity of the reported TA is slot.

§ FFS how to round TA value to slot level granularity

· It is up to RAN2 to decide which component or what combination of the components in the UE’s TA formula to use in TA reporting.

R1-2110663 LS on UE TA reporting RAN1, Ericsson

Decision: As per email decision posted on Oct 21^st, the LS is approved.

Final summary in R1-2110641.

8.4.2 Enhancements on UL time and frequency synchronization

R1-2108720 Considerations on UL timing and frequency synchronization in NTN THALES

R1-2108748 Discussion on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2108910 Discussion on enhancements on UL time and frequency synchronization for NTN Spreadtrum Communications

R1-2108972 Discussion on UL time and frequency synchronization enhancements for NR-NTN vivo

R1-2109077 Discussion on UL time and frequency synchronization OPPO

R1-2109165 Further discussion on synchronization aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2109169 Enhancements on UL Time and Frequency Synchronisation for NR-NTN MediaTek Inc.

R1-2109221 Further discussion on UL time and frequency synchronization enhancement for NTN CATT

R1-2109280 Enhancements on UL time and frequency synchronization for NTN CMCC

R1-2109324 Discussion on NTN uplink time synchronization Lenovo, Motorola Mobility

R1-2109358 Discussion on UL time synchronization for NR NTN NEC

R1-2109410 Discussion on UL time and frequency synchronization for NTN Xiaomi

R1-2109487 Enhancements on UL time and frequency synchronization for NTN Samsung

R1-2109610 On UL synchronization for NTN Intel Corporation

R1-2109676 Discussion on UL time and frequency synchronization enhancements for NTN NTT DOCOMO, INC.

R1-2109764 Discussion on UL time and frequency synchronization enhancement for NTN Baicells

R1-2109787 Considerations on UL time synchronisation Sony

R1-2109826 UL time and frequency synchronization in NTN FGI, Asia Pacific Telecom, III, ITRI

R1-2109844 Discussion on UL synchronization for NR-NTN ZTE

R1-2109858 Enhancements on UL time and frequency synchronization PANASONIC R&D Center Germany

R1-2109879 UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2109928 On UL time and frequency synchronization enhancements for NTN Ericsson

R1-2110032 Discussion on Uplink Time and Frequency Synchronization for NR NTN Apple

R1-2110085 Discussions on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2110184 UL time and frequency synchronization for NTN Qualcomm Incorporated

R1-2110292 Discussion on UL Time Synchronization for NTN Fraunhofer IIS - Fraunhofer HHI

[106bis-e-NR-NTN-02] – Mohamed (Thales)

Email discussion/approval on UL time and frequency synchronization with checkpoints for agreements on October 14 and 19

R1-2108721 FL Summary #1 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Oct 11^th GTW session

Proposal:

When TAC ( in msg2/msgB is received, UE receives the first adjustment and is updated as follows:

Proposal:

One of following options is to be supported:

Option 1: The serving satellite epoch time is set to be the Nth slot after start of SI window of SI message carrying satellite ephemeris

N is optionally signaled with the ephemeris (otherwise 0).

Option 2: Provide the serving satellite epoch time by indicating the SFN and the sub-frame number that the ephemeris data is valid for.
FFS: Whether to use the same epoch time for Common TA and serving satellite ephemeris

R1-2108722 FL Summary #2 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

R1-2108779 FL Summary #3 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Oct 15^th GTW session

Agreement:

Confirm the working assumption:

Common TA may include parameter(s) indicating timing drift.

The UE will apply common TA according to the parameters provided by the network (if any). No offset between the common TA according to the parameters provided by the network and the actual feeder link RTT is considered when defining UE UL timing error requirements.

Agreement:

Common TA Epoch time is implicitly known as a reference time defined by the starting time of a DL slot and/or frame.

FFS: Whether this starting time is given by predefined rule or it is indicated by the Network

Note: “implicitly known” means that UTC is not provided to define the Common TA epoch time.

Agreement:

The UE assumes that it has lost uplink synchronization if new or additional assistance information (i.e. serving satellite ephemeris data or Common TA parameters) is not available within the associated validity duration.

FFS: details on how to acquire new or additional assistance information

Agreement:

NTN ephemeris validity timer should be started/restarted with configured timer validity duration at the epoch time of the assistance information (i.e. serving satellite ephemeris data)

Agreement:

A single validity duration for both serving satellite ephemeris and common TA related parameters is defined at least if serving satellite ephemeris and common TA related parameters are signaled in the same SIB message.

R1-2108780 FL Summary #4 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Oct 18^th GTW session

Proposal:

In NTN, the Network may optionally indicate one or more of the following parameters:

Common TA (delay), Common TA (delay) drift rate and Common TA (delay) drift rate variation.
FFS: Common TA third order derivative.

R1-2108781 FL Summary #5 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Oct 19^th GTW session

Agreement:

In NTN, the Network may optionally indicate one or more of the following parameters:

· Common TA , Common TA drift rate and Common TA drift rate variation.

· FFS: Common TA third order derivative.

· FFS: Details of combination of Common TA parameters

Agreement:

· The granularity of Common TA is set to be

· μ is the highest allowed numerology supported for data, for the given Frequency Range

Conclusion:

Do not define a TA margin.

Working assumption:

· Support serving satellite ephemeris format bit allocations for LEO/MEO/GEO based non-terrestrial access network.:

o Position and velocity state vector ephemeris format [17 bytes payload].

§ The field size for position [m] is [78 bits]

· Position range is driven by GEO : +/- 42 200 km

· The quantization step is [1.3m] for position

§ The field size for velocity [m/s] is [54 bits]

· Velocity range is driven by LEO@600 km: +/- 8000 m/s

· The quantization step is [0.06 m/s] for Velocity

o Orbital parameter ephemeris format [18 byte payload]

§ Semi-major axis α [m] is [33 bits]

· Range: [6500, 43000]km

§ Eccentricity e is [19 bits]

· Range: ≤ 0.015

§ Argument of periapsis ω [rad] is [24 bits]

· Range: [0, 2π]

§ Longitude of ascending node Ω [rad] is [21 bits]

· Range: [-180^o , +180^o]

§ Inclination i [rad] is [20 bits]

· Range: [-90^o , +90^o ]

§ Mean anomaly M [rad] at epoch time t_o is [24 bits]

· Range: [0, 2π]

FFS: Additional enhancement to optimize the signalling overhead.

FFS: Ephemeris format bit allocations for HAPS

R1-2110603 Draft LS on Combination of open and closed loop TA control in NTN Moderator (Thales)

Decision: As per email decision posted on Oct 21^st, the draft LS is endorsed. Final LS is approved in R1-2110604.

Final summary in R1-2110602.

8.4.3 Enhancements on HARQ

R1-2108749 Discussion on HARQ enhancement for NTN Huawei, HiSilicon

R1-2108911 Discussion on enhancements on HARQ for NTN Spreadtrum Communications

R1-2108973 Discussion on HARQ enhancements for NR-NTN vivo

R1-2109078 Discussion on HARQ enhancements OPPO

R1-2109166 Further discussion of aspects related to HARQ for NR over NTN Nokia, Nokia Shanghai Bell

R1-2109170 Enhancements on HARQ for NR NTN MediaTek Inc.

R1-2109222 Further discussion on HARQ operation enhancement for NTN CATT

R1-2109281 Enhancements on HARQ for NTN CMCC

R1-2109344 Enhancements on HARQ to support NTN CAICT

R1-2109359 Discussion on HARQ enhancements for NR NTN NEC

R1-2109411 Discussion on the HARQ enhancement for NTN Xiaomi

R1-2109488 Enhancements on HARQ for NTN Samsung

R1-2109677 Discussion on HARQ enhancements for NR NTN NTT DOCOMO, INC.

R1-2109765 Discussion on HARQ enhancement for NTN Baicells

R1-2109788 Enhancements on HARQ for NTN Sony

R1-2109812 Discussion on HARQ Enhancements for NTN ETRI

R1-2109827 Enhancements on HARQ in NTN FGI, Asia Pacific Telecom, III

R1-2109845 Discussion on HARQ for NR-NTN ZTE

R1-2109868 HARQ enhancement for NTN Panasonic Corporation

R1-2109880 HARQ enhancement for NTN InterDigital, Inc.

R1-2109929 On HARQ enhancements for NTN Ericsson

R1-2109933 Discussion on HARQ enhancements for NTN ITL

R1-2110033 Discussion on HARQ Enhancements for NR NTN Apple

R1-2110086 Discussions on HARQ enhancements in NTN LG Electronics

R1-2110185 Enhancements for HARQ for NTN Qualcomm Incorporated

[106bis-e-NR-NTN-03] – Nan (ZTE)

Email discussion/approval on HARQ enhancements with checkpoints for agreements on October 14 and 19

R1-2110471 Summary#1 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

From Oct 13^th GTW session

Proposal:

For the DCI of PDSCH with feedback-disabled HARQ processes, the following option (from prior agreement) is supported for Type-2 codebook:

Option-1: ~~The UE expects that the C-DAI and T-DAI are~~ ~~the same as the C-DAI and T-DAI of the most recent DCI of PDSCH with feedback-enabled processes, even though are not incremented.~~

For the codebook generation, the UE should use the DAI in DCI of feedback-disabled HARQ process to detect if a previous DCI of feedback-enabled HARQ processes has been missed according to the assumption that the C-DAI and T-DAI are the same as the C-DAI and T-DAI of the feedback-enabled processes transmitted by the gNB. If so, the UE should chose the HARQ codebook size based on the DAI in DCI of the feedback-disabled HARQ process, and the feedback-enabled HARQ process detected to be missed should be NACK.
FFS: the case that all DCIs of PDSCH are associated with feedback-disabled HARQ process

R1-2110532 Summary#2 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

From Oct 15^th GTW session

Agreement:

For DCI indicating SPS PDSCH release, HARQ-ACK report is as in Rel-16.

R1-2110546 Summary#3 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

From Oct 19^th GTW session

Conclusion:

For DCI 0-0/1-0, no enhancement to support indication of more than 16 HARQ processes is considered in Rel-17.

8.4.44 Other

Including the list of topics to specify if beneficial and needed.

R1-2108912 Discussion on beam management and other aspects for NTN Spreadtrum Communications

R1-2108974 Discussion on other aspects for NR-NTN vivo

R1-2109079 Discussion on beam management OPPO

R1-2109167 Further discussion on remaining aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2109223 Beam management and other aspects for NTN CATT

R1-2109282 Other Aspects for NTN CMCC

R1-2109325 Discussion on other aspects for NTN Lenovo, Motorola Mobility

R1-2109360 Remaining issues for NR NTN NEC

R1-2109412 Discussion on other design aspects for NTN Xiaomi

R1-2109489 Remaining issues for NTN Samsung

R1-2109678 Discussion on other aspects for NR NTN NTT DOCOMO, INC.

R1-2109749 Discussion on other design aspects for NTN Huawei, HiSilicon

R1-2109766 Discussion on beam management and other consideration for NTN Baicells

R1-2109789 Discussion on beam management and polarization for NTN Sony

R1-2109828 Other aspects of NR-NTN FGI, Asia Pacific Telecom, III, ITRI

R1-2109846 Discussion on additional enhancement for NR-NTN ZTE

R1-2109881 On beam management for NTN InterDigital, Inc.

R1-2109892 Considerations on NTN with Transparent Payload III

R1-2109930 On other enhancements for NTN Ericsson

R1-2110034 Discussion on Other Aspects of NR NTN Apple

R1-2110087 Discussions on other aspects of NTN LG Electronics

R1-2110186 BWP operation and other issues for NTN Qualcomm Incorporated

R1-2110259 Beam management and polarization signaling for NTN Panasonic

/This one is to use NWM – please use RAN1-106bis-e-NWM-NR-NTN-04 as the document name

[106bis-e-NR-NTN-04] – Hao (OPPO)

Email discussion/approval on other enhancements including list of topics to specify if beneficial and needed with checkpoints for agreements on October 14 and 19

R1-2110489 Summary of the discussions on other enhancements Moderator (OPPO)

From Oct 13^th GTW session

Proposal:

For polarization signalling in SIB, support per SSB polarization indication (up to network whether to use this option to signal this information).

Agreement:

Support polarization signalling for target serving cell in handover command message.

Agreement:

Support polarization signalling for non-serving cell in RRM measurement configuration.

Final summary in R1-2110570.

RAN1#107-e

8.4 Solutions for NR to support non-terrestrial networks (NTN)

Please refer to RP-211784 for detailed scope of the WI.

R1-2112791 Session notes for 8.4 (Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Huawei)

Rel-17 CRs related to NTN

R1-2112432 Introduction of NTN Ericsson

Decision: Draft CR to 38.211 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.

R1-2112447 Introduction of non-terrestrial network operation in NR Samsung

Decision: Draft CR to 38.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.

R1-2112473 Introduction of NR non-terrestrial networks (NTN) Huawei

Decision: Draft CR to 38.212 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.

R1-2112486 Introduction of solutions for NR to support non-terrestrial networks (NTN) Nokia

Decision: Draft CR to 38.211 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.

[107-e-R17-RRC-NR-NTN] – Mohamed (Thales)

Email discussion on Rel-17 RRC parameters for NR to support NTN

- Email discussion to start on November 15

R1-2112849 Summary of [107-e-R17-RRC-NR-NTN] Email discussion on Rel-17 RRC parameters for NR to support NTN Moderator (Thales)

Document is noted. For consolidation under 8 in [107-e-R17-RRC].

R1-2112890 3GPP TSG-RAN WG1 Agreements under 8.4 up to eMeeting RAN1#107-e WI rapporteur (Thales)

8.4.1 Timing relationship enhancements

R1-2110804 Discussion on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2110899 Remaining timing relation aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2111009 Remaining issues on timing relationship enhancements for NR-NTN vivo

R1-2111097 Discussion on timing relationship enhancements for NTN Spreadtrum Communications

R1-2111177 Discussion on timing relationship enhancements for NTN NEC

R1-2111252 Further discussion on timing relationship enhancements for NTN CATT

R1-2111314 Discussion on timing relationship enhancement OPPO

R1-2111353 Remaining issues for timing relationship enhancements in NTN Zhejiang Lab

R1-2111370 Timing relationship enhancements for NR-NTN MediaTek Inc.

R1-2111393 Calculation and application of timing relationship offsets Sony

R1-2111413 On timing relationship enhancements for NTN Ericsson

R1-2111441 Discussion on timing relationship enhancement for NTN Baicells

R1-2111445 Discussions on timing relationship enhancements in NTN SK Telecom, ETRI

R1-2111493 Remaining issues on timing relationships for NTN Intel Corporation

R1-2111570 Discussion on the remaining issues on the timing relationship enhancement for NTN Xiaomi

R1-2111605 Discussion on timing relationship enhancements for NTN CMCC

R1-2111646 Timing relationship for NTN Panasonic Corporation

R1-2111652 Timing relationship enhancements to support NTN CAICT

R1-2111658 Discussion on timing relationship for NR-NTN ZTE

R1-2111734 Timing relationship enhancements for NTN Samsung

R1-2111820 Remaining issues on timing relationship enhancement for NTN InterDigital, Inc.

R1-2111870 Timing Relationship Enhancements for NR NTN Apple

R1-2111968 Discussions on timing relationship enhancements in NTN LG Electronics

R1-2112004 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2112104 Discussion on timing relationship enhancements for NTN NTT DOCOMO, INC.

R1-2112169 Timing relationship enhancements for NTN ITL

R1-2112213 Enhancements on Timing Relationship for NTN Qualcomm Incorporated

[107-e-NR-NTN-01] – Xingqin (Ericsson)

Email discussion/approval on timing relationship enhancements with checkpoints for agreements on November 15 and 19

R1-2112507 Feature lead summary#1 on timing relationship enhancements Moderator (Ericsson)

R1-2112533 Feature lead summary#2 on timing relationship enhancements Moderator (Ericsson)

From Nov 12^th GTW session

Agreement

For defining value range(s) of K_offset, specify one value range of K_offset covering all scenarios

Agreement

For defining value range(s) of K_mac, specify one value range of K_mac covering all scenarios.

Agreement

For determining UE specific K_offset

· Option 2: MAC CE provides a differential UE specific K_offset value. The full UE specific K_offset value equals the cell specific K_offset value minus the differential UE specific K_offset value.

o FFS: whether/how to resolve ambiguity of which cell-specific K_offset value to use during the SIB modification period

Decision: As per email decision posted on Nov 14^th,

Agreement

· 15 kHz is used as the reference subcarrier spacing value for the unit of TA reported in FR1.

Agreement

· The reported TA is the least integer number of slots greater than or equal to the corresponding TA value.

Decision: As per email decision posted on Nov 16^th,

RAN1 endorsed the following proposal as a basis to reply to RAN2 LS on TA pre-compensation (R1-2104230):

RAN1 inputs for the following RAN2 agreements (in italic) are given below:

· Event-triggers for reporting on the information about UE specific TA in connected mode is supported. FFS on the details. Confirmation by RAN1 is also needed

[RAN1]: RAN1 confirms that event-triggers for reporting on the information about UE specific TA in connected mode can be supported.

· The event-triggers for reporting information about UE specific TA are based on TA values (confirmation from RAN1 is needed)

[RAN1]: RAN1 confirms that the event-triggers for reporting information about UE specific TA can be based on TA values.

· Under the work assumption "the UE location information cannot be reported in connected mode", the content of UE specific TA reported in connected mode is UE specific TA pre-compensation(for the details of the TA value, confirmation from RAN1 is needed).

Under the work assumption "the UE location information can be reported in connected mode", for TA reporting purposes in connected mode, the network can configure the UE to send either the UE specific TA pre-compensation (for the details of the TA value, confirmation from RAN1 is needed) or the UE location information

[RAN1]: RAN1 made the following further agreements for the details of the TA value:

Agreement

15 kHz is used as the reference subcarrier spacing value for the unit of TA reported in FR1.

Agreement

The reported TA is the least integer number of slots greater than or equal to the corresponding TA value.

~~Agreement~~ (Proposal 4-A)

The value range of cell specific K_offset is 0 – 542 ms.

~~Agreement~~ (Proposal 5-A)

The value range of K_mac is 1 – 271 ms.

Chair’s Note: Above proposals 4-A and 5-A were agreed by email (Nov16th) but an objection was received subsequently, so decision is reverted and the discussion continues including proposals 4-B and 5-B.

Proposal 4-B

The value range of cell specific K_offset is 0 –1023 ms.

Proposal 5-B

The value range of K_mac is 1 –512 ms.

R1-2112612 Feature lead summary#3 on timing relationship enhancements Moderator (Ericsson)

R1-2112652 DRAFT reply LS on UE TA reporting Ericsson

Decision: As per email decision posted on Nov 19^th, the draft LS is endorsed. Final LS is approved in R1-2112766.

Decision: As per email decision posted on Nov 19^th,

Agreement

The value range of cell specific K_offset is 0 – 1023 ms.

Agreement

The value range of K_mac is 1 – 512 ms.

Agreement

The value range of the differential UE specific K_offset provided in MAC CE is 0 – 63 ms.

Agreement

The K_offset value signaled in system information is always used for PDCCH ordered PRACH timing relationship.

Agreement

Adopt the following TP (38.213, 8.1):

For a PRACH transmission triggered by a PDCCH order, the PRACH mask index field [5, TS 38.212], if the value of the random access preamble index field is not zero, indicates the PRACH occasion for the PRACH transmission where the PRACH occasions are associated with the SS/PBCH block index indicated by the SS/PBCH block index field of the PDCCH order. If UE is provided with K_offset, for a PDCCH order received in downlink slot n, the available PRACH occasion is after uplink slot n+K_offset.

Note: Editor can make further adjustment as appropriate.

Agreement

On beam failure recovery procedure, for PRACH transmission in uplink slot n, UE monitors the corresponding PDCCH starting from downlink slot “n + K_mac + 4” within a corresponding RAR window.

R1-2112647 Feature lead summary#4 on timing relationship enhancements Moderator (Ericsson)

Final summary in R1-2112716.

8.4.2 Enhancements on UL time and frequency synchronization

R1-2110805 Discussion on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2110900 Remaining time and frequency synchronization aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2111010 Remaining issues on UL time and frequency synchronization enhancements for NR-NTN vivo

R1-2111098 Discussion on enhancements on UL time and frequency synchronization for NTN Spreadtrum Communications

R1-2111122 Considerations on UL timing and frequency synchronization in NTN THALES

R1-2111178 Discussion on UL time synchronization for NR NTN NEC

R1-2111253 Further discussion on UL time and frequency synchronization enhancement for NTN CATT

R1-2111315 Discussion on UL time and frequency synchronization OPPO

R1-2111355 Enhancements on UL time and frequency synchronization PANASONIC R&D Center Germany

R1-2111371 Enhancements on UL Time and Frequency Synchronisation for NR-NTN MediaTek Inc.

R1-2111394 Considerations on UL time synchronisation Sony

R1-2111412 Frequency Synchronization Considerations Lockheed Martin

R1-2111414 On UL time and frequency synchronization enhancements for NTN Ericsson

R1-2111442 Discussion on UL time and frequency synchronization enhancement for NTN Baicells

R1-2111494 Remaining issues on synchronization for NTN Intel Corporation

R1-2111571 Discussion on UL time and frequency synchronization for NTN Xiaomi

R1-2111606 Enhancements on UL time and frequency synchronization for NTN CMCC

R1-2111659 Discussion on UL synchronization for NR-NTN ZTE

R1-2111735 Enhancements on UL time and frequency synchronization for NTN Samsung

R1-2111790 Discussion on UL Time Synchronization for NTN Fraunhofer IIS - Fraunhofer HHI

R1-2111821 Remaining issues on UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2111871 Uplink Time and Frequency Synchronization for NR NTN Apple

R1-2111969 Discussions on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2112005 Discussion on NTN uplink time synchronization Lenovo, Motorola Mobility

R1-2112105 Discussion on UL time and frequency synchronization enhancements for NTN NTT DOCOMO, INC.

R1-2112214 UL time and frequency synchronization for NTN Qualcomm Incorporated

[107-e-NR-NTN-02] – Mohamed (Thales)

Email discussion/approval on UL time and frequency synchronization with checkpoints for agreements on November 15 and 19

R1-2111123 FL Summary #1 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Nov 12^th GTW session

Agreement

The serving satellite ephemeris and common TA related parameters are signalled in the same SIB message and have the same epoch time.

Agreement

A single validity duration for both serving satellite ephemeris and common TA related parameters is broadcast on the SIB.

Decision: As per email decision posted on Nov 16^th,

Working assumption

Higher-layer parameters TACommon, TACommonDrift, TACommonDriftVariation and [TACommonThirdOrder] are indicated with the following range, granularity and bits allocation:

Parameter name	Value range	Granularity	Bits allocation
TACommon	0 ...66485757 (i.e: 0… 270.73 ms)	4.07×10-3 μs	26 bits
TACommonDrift	- 261935… + 261935 (i.e: --53.33 μss… +-53.33 μss)	0.2×10-3μss	19 bits
TACommonDriftVariation	0…29470 (0…0.60 μss2)	0.2×10-4μss2	15 bits
[TACommonThirdOrder]	-4912…+4912 (-0.015 μss3…+0.015 μss3)	0.3×10-5μss3	14 bits
Value ranges are given in unit of corresponding granularity

Agreement

NTN validity duration is configured per cell and indicated to the UE in X bits with :

· Value range { 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 120, 180, 240, ~~Infinity~~}

· Unit is second

· FFS (to be resolved in current meeting): Additional values for GEO

Agreement

Confirm the working assumption made at RAN1#106-bis-e on serving satellite ephemeris bit allocations for LEO/MEO/GEO based non-terrestrial access network :

Support serving satellite ephemeris format bit allocations for LEO/MEO/GEO based non-terrestrial access network.:

Position and velocity state vector ephemeris format is 17 bytes payload.

The field size for position (m) is 78 bits

Position range is driven by GEO : +/- 42 200 km
The quantization step is 1.3m for position

The field size for velocity (m/s) is 54 bits

Velocity range is driven by LEO@600 km: +/- 8000 m/s
The quantization step is 0.06 m/s for Velocity

Orbital parameter ephemeris format 18 byte payload

Semi-major axis α (m) is 33 bits

Range: [6500, 43000]km

Eccentricity e is 19 bits

Range: ≤ 0.015

Argument of periapsis ω (rad) is 24 bits

Range: [0, 2π]

Longitude of ascending node (Ω rad) is 21 bits

Range: [0, 2π]

Inclination i (rad) is 20 bits

Range: [- π/2 , + π/2]

Mean anomaly M (rad) at epoch time to is 24 bits

Range: [0, 2π]

R1-2111124 FL Summary #2 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Nov 17^th GTW session

Agreement

The reference point of the epoch time for assistance information (i.e. Serving satellite ephemeris and Common TA parameters) should be known by UE.

· FFS: the definition of the reference point

Conclusion

is UE self-estimated TA to pre-compensate for the service link delay, which is calculated using the UE position and the serving satellite ephemeris.

· How the UE calculates/updates N_{TA, UE-specific} is left to UE implementation.

R1-2111125 FL Summary #3 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

R1-2111126 FL Summary #4 on enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Nov 19^th GTW session

Agreement

Using indicated Higher-layer Common TA parameters, if configured, the UE can determine the one-way propagation time ( used for calculation as follows:

where:

· , and

· TACommon, TACommonDrift and TACommonDriftVariation are Common TA parameters defined in RAN1#106-bis-e

· is the distance between the satellite and the uplink time synchronization reference point divided by the speed of light. DL and UL are frame aligned at the reference point with an offset given by .

· is derived by the UE based on to pre-compensate the two-way transmission delay between the uplink time reference point and the satellite.

Agreement

Confirm the Working assumption on granularity and bits allocation for Common TA parameters: Value range, granularity and bits allocation of Higher-layer parameters TACommon, TACommonDrift, TACommonDriftVariation are as follows:

Parameter name	Value range	Granularity	Bits allocation
	0 ...66485757 (i.e: 0… 270.73 ms)		26 bits
TACommonDrift	- 261935… + 261935 (i.e: --53.33 … +-53.33 )		19 bits
TACommonDriftVariation	0…29470 (0…0.60 )		15 bits
- Value ranges are given in unit of corresponding granularity

Agreement

· When explicitly provided through SIB, Epoch time of assistance information (i.e. Serving satellite ephemeris and Common TA parameters) is the starting time of a DL sub-frame, indicated by a SFN and a sub-frame number signaled together with the assistance information.

· Otherwise, when indicated in SIB (other than SIB1), epoch time of assistance information (i.e. Serving satellite ephemeris and Common TA parameters) is implicitly known as the end of the SI window during which the SI message is transmitted.

· When provided through dedicated signaling, epoch time of assistance information (i.e. Serving satellite ephemeris and Common TA parameters) is the starting time of a DL sub-frame, indicated by a SFN and a sub-frame number.

Agreement

The reference point for epoch time of the serving satellite ephemeris and Common TA parameters is the uplink time synchronization reference point.

Working assumption:

When TAC () in msg2/msgB is received, UE receives the first adjustment and is updated as:

· Option 1: .

where, is the TAC field in msg2/msgB

Decision: As per email decision posted on Nov 20^th,

Conclusion

DL frequency compensation by gNB for the service link Doppler is not supported in Release 17.

Final summary in R1-2111127.

8.4.3 Enhancements on HARQ

R1-2110806 Discussion on HARQ enhancement for NTN Huawei, HiSilicon

R1-2110901 Remaining aspects related to HARQ for NR over NTN Nokia, Nokia Shanghai Bell

R1-2111011 Remaining issues on HARQ enhancements for NR-NTN vivo

R1-2111099 Discussion on enhancements on HARQ for NTN Spreadtrum Communications

R1-2111179 Discussion on HARQ enhancements for NR NTN NEC

R1-2111254 HARQ operation enhancement for NTN CATT

R1-2111316 Discussion on HARQ enhancements OPPO

R1-2111372 Enhancements on HARQ for NR NTN MediaTek Inc.

R1-2111395 Enhancements on HARQ for NTN Sony

R1-2111415 On HARQ enhancements for NTN Ericsson

R1-2111443 Discussion on HARQ enhancement for NTN Baicells

R1-2111572 Discussion on the HARQ enhancement for NTN Xiaomi

R1-2111607 Enhancements on HARQ for NTN CMCC

R1-2111647 HARQ enhancement for NTN Panasonic Corporation

R1-2111653 Enhancements on HARQ to support NTN CAICT

R1-2111660 Discussion on HARQ for NR-NTN ZTE

R1-2111736 Enhancements on HARQ for NTN Samsung

R1-2111822 Remaining issues on HARQ enhancement for NTN InterDigital, Inc.

R1-2111872 HARQ Enhancements for NR NTN Apple

R1-2111970 Discussions on HARQ enhancements in NTN LG Electronics

R1-2111991 Discussion on HARQ Enhancements for NTN ETRI

R1-2112106 Discussion on HARQ enhancements for NR NTN NTT DOCOMO, INC.

R1-2112215 Enhancements on HARQ for NTN Qualcomm Incorporated

R1-2112335 Discussion on HARQ enhancements for NTN ITL

[107-e-NR-NTN-03] – Nan (ZTE)

Email discussion/approval on HARQ enhancements with checkpoints for agreements on November 15 and 19

R1-2112555 Summary#1 of AI 8.4.3 for HARQ in NTN Moderator (ZTE Corporation)

R1-2112663 Summary#2 of AI 8.4.3 for HARQ in NTN Moderator (ZTE Corporation)

From Nov 17^th GTW session

Agreement

The bit-fields related to the HARQ-ACK feedback (i.e., PRI, PUSCH-to-HARQ_feedback timing, DAI) are unchanged for the DCI of PDSCH with feedback-disabled HARQ process in Rel-17 with the same interpretation from UE as for feedback-enabled HARQ process

· Note: The interpretation regarding the DAI for Type-2 codebook is up to the progress of codebook design.

Agreement

For Type-1 HARQ codebook, the UE will consistently report NACK-only for the feedback-disabled HARQ process regardless of decoding results of corresponding PDSCH.

R1-2112664 Summary#3 of AI 8.4.3 for HARQ in NTN Moderator (ZTE Corporation)

From Nov 19^th GTW session

Agreement

For Type-3 HARQ codebook in NTN, the UE should skip the codebook feedback for a feedback-disabled HARQ processes.

Note: The Type-3 codebook size is reduced by excluding the bit positions of disabled HARQ processes.

Agreement

HARQ feedback for SPS activation may be additionally enabled by the network by RRC configuration.

· If enabled, UE reports ACK/NACK for the first SPS PDSCH after activation, regardless of whether HARQ feedback is enabled or disabled corresponding to the first SPS PDSCH after activation

· Otherwise, UE follows configuration of HARQ feedback enabled/disabled corresponding to the first SPS PDSCH after activation,

o FFS between Alt1 and Alt2

· [Alt-1: UE follows the per-process configuration of HARQ feedback enabled/disabled for the associated HARQ process

· Alt-2: UE follows the feedback-enabled/disabled configuration of the SPS PDSCH]

8.4.44 Other

Including the list of topics to specify if beneficial and needed.

R1-2110902 Remaining other aspects for NR over NTN Nokia, Nokia Shanghai Bell

R1-2110903 Discussion on other aspects for NR-NTN BUPT

R1-2111012 Remaining issues on other aspects for NR-NTN vivo

R1-2111100 Discussion on beam management and other aspects for NTN Spreadtrum Communications

R1-2111180 Remaining issues for NR NTN NEC

R1-2111255 Other aspects for NTN CATT

R1-2111317 Discussion on beam management OPPO

R1-2111396 Discussion on beam management and polarization for NTN Sony

R1-2111416 On other enhancements for NTN Ericsson

R1-2111444 Discussion on beam management and other consideration for NTN Baicells

R1-2111573 Discussion on other design aspects for NTN Xiaomi

R1-2111608 Other Aspects for NTN CMCC

R1-2111661 Discussion on additional enhancement for NR-NTN ZTE

R1-2111706 Beam management and polarization signaling for NTN Panasonic

R1-2111737 Remaining issues for NTN Samsung

R1-2111823 Remaining issues on beam management for NTN InterDigital, Inc.

R1-2111873 Other Aspects of NR NTN Apple

R1-2111924 Discussion on other design aspects for NTN Huawei, HiSilicon

R1-2111971 Discussions on other aspects of NTN LG Electronics

R1-2112107 Discussion on other aspects for NR NTN NTT DOCOMO, INC.

R1-2112216 BWP operation and other issues for NTN Qualcomm Incorporated

R1-2112270 Issues on NTN with Transparent Payload III

//Handled under NWM – See RAN1-107-e-NWM-NR-NTN-04 as the document name

[107-e-NR-NTN-04] – Hao (OPPO)

Email discussion/approval on other enhancements including list of topics to specify if beneficial and needed with checkpoints for agreements on November 15 and 19

R1-2112532 Summary#1 of the discussions on other enhancements Moderator (OPPO)

Decision: As per email decision posted on Nov 14^th,

Conclusion

No consensus on the enhancement to support gNB dominant BWP switching based on prediction in NTN-NR R17.

Conclusion

Handling inter-service link interference is not considered in NTN-NR R17.

Conclusion

Handling inter-feeder link interference is not considered in NTN-NR R17.

Decision: As per email decision posted on Nov 16^th,

Conclusion

It is up to gNB implementation to handle BWP_inactivityTimer function, no enhancement is considered in NTN-NR R17.

Decision: As per email decision posted on Nov 20^th,

Conclusion:

No further enhancement is considered for polarization signaling in NTN-NR R17.

No consensus on UE reporting polarization capability.

No consensus on UE behavior for selecting polarization mode for DL reception and UL transmission.

RAN1#107-bis-e

8.44 Maintenance on Solutions for NR to support non-terrestrial networks (NTN)

Void (not be handled during this e-meeting).

R1-2200674 MEO Scenarios and Characteristics HUGHES Network Systems Ltd

Decision: The document is withdrawn as the content does touch upon NR NTN which is not the scope of RAN1#107bis-e.

RAN1#108-e

8.4 Maintenance on Solutions for NR to support non-terrestrial networks (NTN)

R1-2202784 Session notes for 8.4 (Maintenance on Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Huawei)

[108-e-R17-RRC-NR-NTN] – Mohamed (Thales)

Email discussion on Rel-17 RRC parameters for NR to support NTN

- 1^st check point for first LS in [108-e-R17-RRC]: February 24

- Final check point for second LS in [108-e-R17-RRC] if necessary: March 3

R1-2202909 Summary of [108-e-R17-RRC-NR-NTN] Email discussion on Rel-17 RRC parameters for NR to support NTN Moderator (Thales)

Document is noted. For consolidation under 8 in [108-e-R17-RRC].

R1-2201184 TP for RAN1 additions to the stg2 CR for TS 38.300 THALES

R1-2202489 MEO Scenarios and Characteristics HUGHES Network Systems Ltd

[108-e-R17-NR-NTN-05] – Mohamed (THALES)

Email discussion on NR-NTN TP for TS38.300 (R1-2201184) by February 24

Decision: As per email posted on Feb 24^th, TP proposed for TR38.821 from R1-2202489 is for discussion using this email thread. TR38.821 is a Rel-16 TR from RAN3, so any endorsed TP by RAN1 should be sent to RAN3 with the assumption that this for an update of the TR for Rel-16.

R1-2202872 Email discussion on NR-NTN TP for TS 38.300 Moderator (Thales)

R1-2202836 RAN1 NR NTN additions for TS 38.300 Moderator (Thales)

Decision: As per email decision posted on Mar 2^nd, the draftCR for TS38.300 is endorsed in R1-2202836, and shall be attached to the LS to RAN2.

Regarding the TP to TR 38.821, no consensus on the TP nor on the FL proposal.

R1-2202837 Draft LS on NR-NTN TP for TS 38.300 Moderator (Thales)

Decision: As per email decision posted on Mar 2^nd, the draft LS is endorsed. Final version is approved in R1-2202838.

R1-2202910 RAN WG1 Agreements under 8.4 up to e-Meeting RAN1#108-e WI rapporteur (Thales)

8.4.1 Timing relationship enhancements

R1-2200937 Maintenance on timing relationship enhancements for NTN Huawei, HiSilicon

R1-2201215 Timing relationship enhancements for NR-NTN MediaTek Inc.

R1-2201271 Discussion on remaining issue for timing relationship enhancement OPPO

R1-2201358 Remaining issues on timing relationship enhancements for NTN CATT

R1-2201546 Discussion on timing relationship enhancements for NTN Spreadtrum Communications

R1-2201645 Maintenance aspects of time relations for Rel-17 NR over NTN Nokia, Nokia Shanghai Bell

R1-2201744 Remaining issues on timing relationship enhancement for NTN InterDigital, Inc.

R1-2201771 Remaining Issues of Timing Relationship Enhancements for NR NTN Apple

R1-2201804 On timing relationship maintenance issues for NR NTN Ericsson Hungary Ltd

R1-2201852 Remaining issues on timing relationship enhancements for NTN CMCC

R1-2201921 Remaining issues on the timing relationship for NTN Xiaomi

R1-2201969 Discussion on NTN timing relationship Lenovo, Motorola Mobility

R1-2202011 Maintenance issues on Timing relationship enhancements for NTN Samsung

R1-2202206 Remaining issues of timing relationship for NR-NTN ZTE

R1-2202241 Remaining issues on timing relationship enhancement for NTN Baicells

R1-2202285 Remaining issues on timing relationship enhancements in NTN LG Electronics

R1-2202360 Remaining issues on timing relationship enhancements for NTN NEC

[108-e-R17-NR-NTN-01] – Jussi (Huawei)

Email discussion for maintenance on timing relationship enhancements

- 1^st check point: February 25

- Final check point: March 3

R1-2202606 FL summary #2 on NTN timing relationships Moderator (Huawei) (rev of R1-2202526)

From Feb 23^rd GTW session

Conclusion

The additional delay introduced for the starts of ra-ResponseWindow and msgB-ResponseWindow should only apply to NTN. Continue discussion on a TP to TS38.213 sections 8.2 and 8.2A, such as:

“If or is different from zero, the window starts after an additional msec …”

Agreement

Send a reply LS to RAN2, indicating

· RAN1 has no concern with the list of nine parameters of serving cell information

· RAN1 proposes two additional parameters (ntnPolarizationDL and ntnPolarizationUL) to be added into the parameters of serving cell information, including the relevant RAN1 agreements

Continue discussion to clarify RAN1 understanding regarding the validity duration for UL sync information, and whether this would impact the SIBx design.

Reply to

R1-2200875 LS on NTN-specific SIB RAN2, Huawei

R1-2202794 Draft reply LS on NTN-specific SIB Moderator (Huawei) (rev of R1-2202696)

Decision: As per decision on Mar 2^nd, GTW session, the draft LS is endorsed with the following change:

~~With respect to the validity duration, RAN1 understanding is that it only applies to ephemeris and common TA parameters, and the other parameters follow the normal SI modification procedure.~~

RAN1 looked at the recent RAN2 agreement on system information update:

1. Update of ephemeris and common TA information does not affect the value tag and does not trigger SI modification procedure.
2. The ntnUlSyncValidityDuration applies to the whole SIBX. UE acquires the updated SIBX when the timer expires. FFS whether to also include it in the LS to RAN1. FFS if this applies only to Connected mode or to idle mode UE as well

With respect to the validity duration, RAN1 understanding is that it only applies to ephemeris and common TA parameters including the epoch time, and the other parameters follow the normal SI modification procedure.

~~From this agreement RAN1 has the understanding that there is no relation between the update of ephemeris and common TA information and the parameters other than those two~~

Some of these other parameters (e.g. K_offset) will impact the UE’s UL transmit timing.

For several meetings RAN1 has been discussing whether there is a need to resolve ambiguity of which cell-specific K_offset value to use during the SIB modification period and the majority of companies think that it can be handled by gNB implementation. According to some companies this potential ambiguity has to be resolved in the specifications. RAN1 respectfully asks RAN2 to share their understanding on whether there is a need to address this potential ambiguity.

Final LS is approved in R1-2202843.

Decision: As per email decision posted on Feb 25^th,

Conclusion

Update of K_mac with MAC CE is not supported in Rel-17 NTN.

Conclusion

The size of the PDSCH-to-HARQ_feedback timing indicator field in DCI is not extended when the range of the K1 value is extended in Rel-17 NTN

Conclusion

K_offset is not introduced for type 1 configured grant in Rel-17 NTN.

Conclusion

Beam-specific K_offset is not supported for initial access in Rel-17 NTN.

Agreement

Adopt the following TP for instances of “ is provided by Koffset in ServingCellConfigCommon” TS38.213: “where is provided by ~~Koffset~~ in ~~ServingCellConfigCommon~~ CellSpecific_Koffset”

Agreement

Adopt the following TP for Section 6.2.1 of TS38.214:

Agreement

In TS38.213 sections 8.2 and 8.2A, make the following change:

“If or as specified in [TS38.211 clause 4.3.1] is different from zero, the window starts after an additional msec …”

Decision: As per email decision posted on Feb 26^th,

Agreement

Adopt the following TP for Section 5.2.2.5 of TS38.214:

--- Start of TP ---

5.2.2.5 CSI reference resource definition

The CSI reference resource for a serving cell is defined as follows:

- In the frequency domain, the CSI reference resource is defined by the group of downlink physical resource blocks corresponding to the band to which the derived CSI relates.

- In the time domain, the CSI reference resource for a CSI reporting in uplink slot n' is defined by a single downlink slot , if UE is configured with the higher layer parameter CellSpecific_Koffset, n~~-n_{CSI_ref}, ,~~ where is a parameter configured by higher layer as specified in [TS 38.213 clause 4.2], and where is the subcarrier spacing configuration for with a value of 0 for frequency range 1, ~~otherwise,~~

- ~~is provided with a value of ms for frequency range 1 and is equal to CellSpecific_Koffset - UESpecific_Koffset if UESpecific_Koffset is provided in MAC CE and CellSpecific_Koffset, otherwise;~~

- where and and are the subcarrier spacing configurations for DL and UL, respectively, and and are determined by higher-layer configured ca-SlotOffset for the cells transmitting the uplink and downlink, as defined in clause 4.5 of [4, TS 38.211]

--- End of TP ---

Agreement

Adopt the following TP for Section 6.1.2.1 of TS38.214:

--- Start of TP ---

6.1.2.1 Resource allocation in time domain

<<< unchanged paragraphs omitted >>>

in CSI-ReportConfig for the triggered CSI Reporting Settings and is the (m+1)th entry of .

- The slot K_s where the UE shall transmit the PUSCH is determined by K₂ as K_s=, if UE is configured with ca-SlotOffset for at least one of the scheduled and scheduling cell, , otherwise, where is a parameter configured by higher layer as specified in [TS38.213 clause 4.2] ~~if the UE is configured with the higher layer parameter CellSpecific_Koffset, K_s=, otherwise~~, and where is the subcarrier spacing configuration for with a value of 0 for frequency range 1, n is the slot with the scheduling DCI, K₂ is based on the numerology of PUSCH, and are the subcarrier spacing configurations for PUSCH and PDCCH, respectively, ~~is provided with a value of ms for frequency range 1 and is equal to CellSpecific_Koffset - UESpecific_Koffset if UESpecific_Koffset is provided in MAC CE~~ and the scheduling DCI is other than DCI format 0_0 with CRC scrambled by TC-RNTI~~, and CellSpecific_Koffset otherwise~~.

--- End of TP ---

Agreement

Adopt the following TP for Section 6.2.1 of TS38.214:

--- Start of TP ---

6.2.1 UE sounding procedure

- If the UE receives the DCI triggering aperiodic SRS in slot n and none of the resource sets is configured with parameter availableSlotOffset across all configured BWPs in a component carrier, and if the UE is configured with ca-SlotOffset for at least one of the triggered and triggering cell, except when SRS is configured with the higher layer parameter SRS-PosResource, the UE transmits aperiodic SRS in each of the triggered SRS resource set(s) in slot , otherwise, the UE transmits aperiodic SRS in each of the triggered resource set(s) in slot, where is a parameter configured by higher layer as specified in [TS38.213 clause 4.2] ~~if the UE is configured with the higher layer parameter CellSpecific_Koffset, K_s=, otherwise~~, and where

- k is configured via higher layer parameter slotOffset for each triggered SRS resources set and is based on the subcarrier spacing of the triggered SRS transmission, µ_SRS and µ_PDCCH are the subcarrier spacing configurations for triggered SRS and PDCCH carrying the triggering command respectively;

- is the subcarrier spacing configuration for with a value of 0 for frequency range 1~~, and~~ ~~is provided with a value of ms for frequency range 1 and is equal to CellSpecific_Koffset -UESpecific_Koffset if UESpecific_Koffset is provided in MAC CE and CellSpecific_Koffset otherwise~~.

- and are the and the, respectively, which are determined by higher-layer configured ca-SlotOffset for the cell receiving the PDCCH, and are the and the , respectively, which are determined by higher-layer configured ca-SlotOffset for the cell transmitting the SRS, as defined in [4, TS 38.211] clause 4.5.

- If the UE receives the DCI triggering aperiodic SRS in slot n and when SRS is configured with the higher layer parameter SRS-PosResource, the UE transmits every aperiodic SRS resource in each of the triggered SRS resource set(s) in slot , if UE is configured with ca-SlotOffset for at least one of the triggered and triggering cell, , otherwise, where is a parameter configured by higher layer as specified in [TS 38.213 clause 4.2] ~~if UE is configured with the higher layer parameter CellSpecific_Koffset, K_s=, otherwise~~, and where

- k is configured via higher layer parameter slotOffset for each aperiodic SRS resource in each triggered SRS resources set and is based on the subcarrier spacing of the triggered SRS transmission, µ_SRS and µ_PDCCH are the subcarrier spacing configurations for triggered SRS and PDCCH carrying the triggering command respectively;

- is the subcarrier spacing configuration for with a value of 0 for frequency range 1.

- ~~is provided with a value of ms for frequency range 1 and is equal to CellSpecific_Koffset -UESpecific_Koffset if UESpecific_Koffset is provided in MAC CE and CellSpecific_Koffset otherwise.~~

--- End of TP ---

R1-2202811 FL summary #5 on NTN timing relationships Moderator (Huawei)

Decision: As per email decision posted on Mar 2^nd,

Agreements

· Text Proposal TP#3B (for 38.213, Clause 9) in section 11.2 of R1-2202811 is endorsed.

· Text Proposal TP#9C (for 38.214, Clause 5.1.4.2) in section 11.7 of R1-2202811 is endorsed.

· Text Proposal TP#10C (for 38.214, Clause 5.1.5) in section 11.8 of R1-2202811 is endorsed.

· Text Proposal TP#11C (for 38.214, Clause 5.2.1.5.1) in section 11.9 of R1-2202811 is endorsed.

· Text Proposal TP#12C (for 38.214, Clause 5.2.1.5.2) in section 11.10 of R1-2202811 is endorsed.

Conclusion

Regarding the delay between PDCCH reception and application of new PUCCH beam, “28 symbols” is the absolute time between the time UE receives PDCCH and the time UE applies new PUCCH beam.

8.4.2 Enhancements on UL time and frequency synchronization

R1-2200938 Maintenance on UL time and frequency synchronization enhancement for NTN Huawei, HiSilicon

R1-2201011 Maintenance on UL timing and frequency synchronization in NTN THALES

R1-2201216 Enhancements on UL Time and Frequency Synchronisation for NR-NTN MediaTek Inc.

R1-2201272 Discussion on remaining issue for UL time and frequency synchronization OPPO

R1-2201359 Remaining issues on UL time and frequency synchronization enhancement for NTN CATT

R1-2201387 Enhancements on UL time and frequency synchronization PANASONIC R&D Center Germany

R1-2201477 Remaining issues on UL time and frequency synchronization enhancements for NTN NTT DOCOMO, INC.

R1-2201547 Discussion on enhancements on UL time and frequency synchronization for NTN Spreadtrum Communications

R1-2201581 Discussion on ambiguity of common TA calculation Sony

R1-2201646 Maintenance aspects of time and frequency synchronization for Rel-17 NR over NTN Nokia, Nokia Shanghai Bell

R1-2201745 Remaining issues on UL time/frequency synchronization for NTN InterDigital, Inc.

R1-2201772 Remaining Issues of Uplink Time and Frequency Synchronization for NR NTN Apple

R1-2201805 On UL time and frequency synchronization maintenance issues for NTN Ericsson Hungary Ltd

R1-2201853 Remaining issues on enhancements on UL time and frequency synchronization for NTN CMCC

R1-2201922 Remaining issues on UL time and frequency synchronization for NTN Xiaomi

R1-2202012 Maintenance issues on UL time and frequency synchronization for NTN Samsung

R1-2202138 Remaining issues on UL time and frequency synchronization for NTN Qualcomm Incorporated

R1-2202207 Remaining issues of UL synchronization for NR-NTN ZTE

R1-2202286 Remaining issues on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2202359 Remaining issues on UL time and frequency synchronization enhancement for NTN Baicells

R1-2202361 Remaining issues on UL time synchronization for NR NTN NEC

[108-e-R17-NR-NTN-02] – Mohamed (Thales)

Email discussion for maintenance on UL time and frequency synchronization

- 1^st check point: February 25

- Final check point: March 3

R1-2202551 FL Summary #1 :Enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Feb 23^rd GTW session

Agreement

Modify second bullet of RAN1#107-e agreement on Epoch time as follows:

Otherwise, when Epoch time is not explicitly indicated in SIB ~~(other than SIB1),~~ epoch time of assistance information (i.e. Serving satellite ephemeris and Common TA parameters) is implicitly known as the end of the SI window during which the NTN-specific SIB ~~SI message~~ is transmitted.

Agreement

· Add one additional NTN validity duration value for GEO i.e. 900 seconds. X = 4 bits.

R1-2202552 FL Summary #2 :Enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

From Feb 25^th GTW session

Agreement

Modify bit allocations for orbital parameters ephemeris format as follows:

· Orbital parameters are indicated in 21 bytes payload:

Semi-major axis α (m) is 33 bits

Range: from 6500 km to 43000 km
The quantization step is 4.249 m

Eccentricity e is 20 bits

Range: ≤ 0.015
The quantization step is 1.431

Argument of periapsis ω (rad) is 28 bits

Range: from 0 to 2π
The quantization step is 2.341 rad

Longitude of ascending node (Ω rad) is 28 bits

Range: from 0 to 2π
The quantization step is 2.341 rad

Inclination i (rad) is 27 bits

Range: from - π/2 to + π/2
The quantization step is 2.341 rad

Mean anomaly M (rad) at epoch time to is 28 bits

Range: from 0 to 2π
The quantization step is 2.341 rad

Decision: As per email decision posted on Mar 2^nd,

Conclusion

Confirm that the agreed position and velocity state vector ephemeris format for LEO/MEO/GEO may also be applied for HAPS/ATG.

R1-2200883 Reply LS on NR NTN Neighbor Cell and Satellite Information RAN2, Qualcomm

R1-2202710 Draft Reply LS to RAN2 on NR NTN Neighbour Cell and Satellite Information Moderator (Thales)

R1-2202711 Draft Reply LS to RAN2 on NR NTN Neighbour Cell and Satellite Information Moderator (Thales)

Decision: As per decision on Mar 2^nd, GTW session, the draft LS is endorsed with the following change:

RAN1 answer: From RAN1 perspective, if configured on neighbour/target cell, A2/B2 (high-layer common TA parameters: TACommon, TACommonDrift and TACommonDriftVariation) ~~are necessary~~can be helpful for measurement ~~purpose~~ and are necessary for mobility purpose (in case of network assisted cell change/handover),

Final LS is approved in R1-2202873.

R1-2202553 FL Summary #3 :Enhancements on UL time and frequency synchronization for NR NTN Moderator (Thales)

Decision: As per email decision posted on Mar 3^rd,

Agreement

· The text proposal (for TS 38.211 clause 3.1) of updated proposal 11-1 in section 16 of R1-2202553 is endorsed.

Final summary in R1-2202908.

8.4.3 Enhancements on HARQ

R1-2200939 Maintenance on HARQ enhancement for NTN Huawei, HiSilicon

R1-2201092 Remaining issues on HARQ enhancements for NR-NTN vivo

R1-2201273 Discussion on remaining issue for HARQ enhancements OPPO

R1-2201360 Remaining issues on HARQ operation enhancement for NTN CATT

R1-2201478 Remaining issues on HARQ enhancements for NR NTN NTT DOCOMO, INC.

R1-2201548 Discussion on enhancements on HARQ for NTN Spreadtrum Communications

R1-2201633 HARQ enhancement for NTN Panasonic Corporation

R1-2201647 Maintenance aspects related to HARQ for Rel-17 NR over NTN Nokia, Nokia Shanghai Bell

R1-2201746 Remaining issues on HARQ enhancement for NTN InterDigital, Inc.

R1-2201773 Remaining Issue of HARQ Enhancements for NR NTN Apple

R1-2201806 On HARQ maintenance issues for NR NTN Ericsson Hungary Ltd

R1-2201854 Remaining issues on enhancements on HARQ for NTN CMCC

R1-2201923 Discussion on HARQ for NTN Xiaomi

R1-2201960 Remaining issues on enhancements on HARQ to support NTN CAICT

R1-2202013 Maintenance issues on HARQ aspects for NTN Samsung

R1-2202139 Remaining issues on HARQ for NTN Qualcomm Incorporated

R1-2202208 Remaining issues of HARQ for NR-NTN ZTE

R1-2202242 Remaining issues on HARQ enhancement for NTN Baicells

R1-2202287 Remaining issues on HARQ enhancements in NTN LG Electronics

R1-2202362 Remaining issues on HARQ enhancements for NR NTN NEC

[108-e-R17-NR-NTN-03] – Nan (ZTE)

Email discussion for maintenance on HARQ enhancements

- 1^st check point: February 25

- Final check point: March 3

R1-2202622 Summary#1 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

From Feb 25^th GTW session

Agreement

For HARQ feedback of each SPS PDSCH, UE follows the per-process configuration of HARQ feedback enabled/disabled for the associated HARQ process, except for the first SPS PDSCH after activation if HARQ feedback for SPS activation is additionally enabled.

Decision: As per email decision posted on Feb 26^th,

Agreement

Update the RAN1#105-e agreement and apply the following TP.

· Confirm the previous working assumption for X = T_proc,1 where X is defined from the end of the reception of the last PDSCH or slot-aggregated PDSCH for a given HARQ process with disabled feedback to the start of the PDCCH carrying the DCI scheduling another PDSCH or set of slot-aggregated PDSCH or the PDSCH without corresponding PDCCH for the given HARQ process.

----------------------------------------Start of TP 38.214 V17.0.0 section 5.1 ----------------------------------

5.1 UE procedure for receiving the physical downlink shared channel

When HARQ feedback for the HARQ process ID is not disabled, the UE is not expected to receive another PDSCH for a given HARQ process until after the end of the expected transmission of HARQ-ACK for that HARQ process, where the timing is given by Clause 9.2.3 of [6, TS 38.213]. For HARQ-ACK subject to HARQ-ACK deferral described in Clause 9.2.5.4 of [6 TS 38.213], the expected transmission of HARQ-ACK corresponds to the expected transmission HARQ-ACK in a first slot. When HARQ feedback for the HARQ process ID is disabled, the UE is not expected to receive another PDCCH carrying a DCI scheduling a PDSCH or set of slot-aggregated PDSCH scheduled for the given HARQ process or to receive another PDSCH without corresponding PDCCH ~~scheduled~~ for the given HARQ process that starts until T_proc,1 after the end of the reception of the last PDSCH or slot-aggregated PDSCH for that HARQ process.

----------------------------------------End of TP 38.214 V17.0.0 section 5.1 -----------------------------------

Agreement

Adopt the following TP (38.214, Section 5.1):

----------------------------------------Start of TP 38.214 V17.0.0 section 5.1 ---------------------------------------------

5.1 UE procedure for receiving the physical downlink shared channel

A UE shall upon detection of a PDCCH with a configured DCI format 1_0, 1_1 or 1_2 decode the corresponding PDSCHs as indicated by that DCI. When the UE is scheduled with multiple PDSCHs by a DCI, HARQ process ID indicated by this DCI applies to the first PDSCH not overlapping with a UL symbol indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated if provided, HARQ process ID is then incremented by 1 for each subsequent PDSCH(s) in the scheduled order, with modulo operation of nrofHARQ-ProcessesForPDSCH applied. HARQ process ID is not incremented for PDSCH(s) not received if at least one of the symbols indicated by the indexed row of the used resource allocation table in the slot overlaps with a UL symbol indicated by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigurationDedicated if provided. For any HARQ process ID(s) in a given scheduled cell, the UE is not expected to receive a PDSCH that overlaps in time with another PDSCH. When HARQ feedback for the HARQ process ID is not disabled, or for the HARQ process associated with the first SPS PDSCH when HARQ-feedbackEnablingforSPSactive is provided, the UE is not expected to receive another PDSCH for a given HARQ process until after the end of the expected transmission of HARQ-ACK for that HARQ process, where the timing is given by Clause 9.2.3 of [6, TS 38.213]. For HARQ-ACK subject to HARQ-ACK deferral described in Clause 9.2.5.4 of [6 TS 38.213], the expected transmission of HARQ-ACK corresponds to the expected transmission HARQ-ACK in a first slot.

----------------------------------------Start of TP 38.214 V17.0.0 section 5.1 ---------------------------------------------

R1-2202623 Summary#2 of AI 8.4.3 for HARQ in NTN Moderator (ZTE)

Decision: As per email decision posted on Mar 2^nd,

Agreements

· The TP (for TS 38.214 clause 5.3) in [Initial Proposal 3.2.1-1] in section 3.2 of R1-2202623 is endorsed.

· The TP (for TS 38.214 clause 5.1 and 6.1) in [Initial Proposal 4.2.1-1] in section 4.2 of R1-2202623 is endorsed.

8.4.44 Other

R1-2201479 Remaining issues on other aspects for NR NTN NTT DOCOMO, INC.

R1-2201648 Maintenance aspects of RRC parameters for Rel-17 NR over NTN Nokia, Nokia Shanghai Bell

R1-2201812 On other maintenance issues for NR NTN Ericsson Hungary Ltd

R1-2201855 Other Aspects for NTN CMCC

R1-2202209 Remaining issues of additional enhancement for NR-NTN ZTE

R1-2202364 Remaining issues for NR NTN NEC

R1-2202424 Discussion on other design aspects for NTN Huawei, HiSilicon

[108-e-R17-NR-NTN-04] – Hao (OPPO)

Email discussion/approval on maintenance related to signaling of polarization information

- 1^st check point: February 25

- Final check point: March 3

R1-2202601 Summary#1 of discussion on maintenance related to signaling of polarization information Moderator (OPPO)

Decision: As per email decision posted on Mar 2^nd,

Conclusion

NTN-NR R17 does not support per-beam polarization signaling for any deployment scenarios.

RAN1#109-e

8.44 Maintenance on Solutions for NR to support non-terrestrial networks (NTN)

R1-2205562 Session notes for 8.4 (Maintenance on Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Huawei)

R1-2205120 Moderator Summary for preparation phase on maintenance of Rel-17 WI on Solutions for NR to support non-terrestrial networks (NTN) Moderator (Thales)

R1-2203088 Maintenance on solutions for NR to support NTN Huawei, HiSilicon

R1-2203231 Remaining issues on NR-NTN ZTE

R1-2203289 Maintenance on Solutions for NR to support non-terrestrial networks (NTN) PANASONIC R&D Center Germany

R1-2203306 Maintenance on Solutions for NR to support non-terrestrial networks (NTN) Spreadtrum Communications

R1-2203385 Maintenance on Solutions for NR to support NTN MediaTek Inc.

R1-2203721 Discussion on ambiguity of common TA calculation Sony

R1-2203756 Maintenance on NR NTN CATT

R1-2203770 Discussion on maintenance issues in NR-NTN xiaomi

R1-2203843 Maintenance aspects af Rel-17 NR over NTN Nokia, Nokia Shanghai Bell

R1-2203935 Discussion on the remaining issues in R17 NR NTN NEC

R1-2203990 Discussion on remaining issue for NTN-NR OPPO

R1-2204207 On remaining issues of NR NTN Apple

R1-2204345 Remaining issues on NR NTN NTT DOCOMO, INC.

R1-2204519 Remaining issues on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2204556 Maintenance on Release-17 NR NTN THALES

R1-2204660 On NR NTN maintenance issues Ericsson

R1-2204933 Enhancements on UL time and frequency synchronization Mavenir

R1-2204984 Maintenance on NR NTN Qualcomm Incorporated

[109-e-R17-NR-NTN-01] – Mohamed (Thales)

Email discussion for maintenance on timing relationship enhancements and UL time and frequency synchronization for NR NTN, for issues 1-2, 1-3, 1-4, 1-5, 1-6, 1-7, 1-8, 1-10, 1-14 in R1-2205120, taking into account LS received in R1-2203019 and R1-2203020

- 1^st check point: May 13 (any RRC impact by May 12)

- Final check point: May 18

R1-2205337 FL Summary #1: Maintenance on timing relationship enhancements and UL time and frequency synchronization for NR NTN Moderator (Thales)

Decision: As per email decision posted on May 13^th,

Agreement

For ephemeris set 2, RAN1 agree on orbital parameters α , e, ω , Ω , I, and M in Earth Centered Inertial (ECI) Frame

· The ECI and ECEF coincide at Epoch time (e.g. x,y,z axis in ECEF are aligned with x,y,z axis in ECI)

Agreement

· Text Proposal 09- v01 (for TS38.213 v17.1.0, clause 4.2) in section 9.3 of R1-2205337 is endorsed.

R1-2205338 FL Summary #2: Maintenance on timing relationship enhancements and UL time and frequency synchronization for NR NTN Moderator (Thales)

Decision: As per email decision posted on May 17^th,

Agreement

· Text Proposal 12 (for TS38.211 v17.1.0, clause 4.3.1) in section 12 of R1-2205338 is endorsed.

Decision: As per email decision posted on May 19^th,

Agreement

For DCI scheduled PUSCH including CSI on PUSCH and aperiodic SRS and for HARQ-ACK on PUCCH, the UE-specific K_offset valid at the slot of the associated DCI being received is applied.

Final summary in R1-2205489.

[109-e-R17-NR-NTN-02] – Nan (ZTE)

Email discussion for maintenance on scheduling and HARQ for NR NTN, for issues 2-1, 2-2 and 2-3 in R1-2205120

- 1^st check point: May 13 (any RRC impact by May 12)

- Final check point: May 18

R1-2205232 Summary#1 of Email discussion for maintenance on scheduling and HARQ for NR NTN Moderator (ZTE)

Decision: As per email decision posted on May 13^th,

Agreement

· TP1 (for TS38.213 v17.1.0, clause 9.1.3.1) in section 4.1.1 of R1-2205232 is endorsed.

· TP2 (for TS38.213 v17.1.0, clause 9) in section 4.1.2 of R1-2205232 is endorsed.

R1-2205339 Summary#2 of Email discussion for maintenance on scheduling and HARQ for NR NTN Moderator (ZTE)

Decision: As per email decision posted on May 17^th,

Agreement

For the HARQ-ACKs feedback of SPS PDSCHs in Type-2 codebook, if the HARQ process of a SPS PDSCH for a transport block is indicated as disabled HARQ-ACK information by HARQ-feedbackEnabling-disablingperHARQprocess, no feedback is expected for this SPS PDSCH.

Final summary in R1-2205384.

RAN1#110

8.44 Maintenance on Solutions for NR to support non-terrestrial networks (NTN)

R1-2208135 Session notes for 8.4 (Maintenance on Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Huawei)

[110-R17-NR_NTN] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Mohamed (Thales)

R1-2205809 Correction on HARQ-ACK transmission in NTN Huawei, HiSilicon

R1-2205828 Maintenance on Release-17 NR NTN THALES

R1-2205833 Discussion on Common TA Drift Variation Lockheed Martin

R1-2205973 Maintenance on Solutions for NR to support non-terrestrial networks (NTN) Spreadtrum Communications

R1-2206013 Remaining issues on NR-NTN ZTE

R1-2206014 Corrections on NR-NTN synchronization ZTE

R1-2206157 Maintenance on Solutions for NR to support NTN MediaTek Inc.

R1-2206178 Maintenance on Solutions for NR to support non-terrestrial networks (NTN) PANASONIC

R1-2206233 Correction on HARQ process number for NTN ASUSTeK

R1-2206295 Discussion on remaining issue for NTN-NR OPPO

R1-2206296 Draft CR on time relationship for MAC-CE activation OPPO

R1-2206854 Draft CR on interpretation SFN indicating epoch time OPPO

R1-2206855 Draft CR on editorial correction on Koffset MAC CE command OPPO

R1-2207137 Further aspects of Rel-17 maintenance of NR over NTN Nokia, Nokia Shanghai Bell

R1-2207138 Draft CR for 38.211 to ensure correct interworking between open and closed loop TA Nokia, Nokia Shanghai Bell

R1-2207139 Draft CR for 38.213 to capture correct validity timer expiry behavior for UL synchronization Nokia, Nokia Shanghai Bell

R1-2207193 Maintenance for R17 NR NTN Qualcomm Incorporated

R1-2207311 Maintenance on NR NTN Apple

R1-2207357 Remaining issues on UL time and frequency synchronization enhancements in NTN LG Electronics

R1-2207496 Correction on HARQ feedback enabling for NTN ASUSTeK

R1-2207497 Correction on HARQ feedback enabling for the first SPS PDSCH ASUSTeK

R1-2207512 Correction on UE-specific TA for NTN Huawei, HiSilicon

R1-2207554 On NR NTN maintenance issues Ericsson

R1-2207666 Discussion on interpretation of SFN indicating Epoch time Huawei, HiSilicon

R1-2207632 FL Summary #1: Maintenance on UL time/frequency synchronization and timing relationship for NR NTN THALES

Agreement

· The TP in R1-2206855 is endorsed and provided to the TS 38.213 editor for aligning the name of UE-specific Koffset in TS 38.213 with Differential Koffset in TS 38.321.

R1-2207633 FL Summary #2: Maintenance on UL time/frequency synchronization and timing relationship for NR NTN THALES

Agreement

· For serving cell if EpochTime is indicated explicitly by a SFN and subframe number, the UE considers this frame to be the current SFN or the next upcoming SFN after the frame where the message indicating the Epoch time is received.

· For neighbor cell if EpochTime is indicated explicitly by a SFN and subframe number, the UE considers this frame to be the frame nearest to the frame where the message indicating the Epoch time is received.

Conclusion

Negative values of CommonDelayDriftVariation for GEO are not indicated.

Final summary in R1-2207634.

R1-2207687 Summary#1 of maintenance on scheduling and HARQ for NR NTN Moderator (ZTE)

Agreement

· Adopt the TP for 38.213 Section 9.2.3 in [Updated Proposal 1.1-1]-TP1 in R1-2207687.

Final CR (38.213, Rel-17, CR#0339r1, Cat F) is agreed in R1-2208124.

R1-2208124 CR on the clarification of PUCCH resource determination in 38.213 Moderator (ZTE), Huawei, HiSilicon, Xiaomi, OPPO, Ericsson

Agreement

· Adopt the TP for 38.213 Section 9 in [Initial Proposal 2.2.1-1]-TP2 in R1-2207687.

Final CR (38.213, Rel-17, CR#0340r1, Cat F) is agreed in R1-2208125.

R1-2208125 CR on the description about HARQ-feedbackEnablingforSPSactive in 38.213 Moderator (ZTE), Huawei, HiSilicon, ASUSTek, Xiaomi, OPPO, Ericsson

Agreement

· Adopt the TP for 38.214 Section 5.1 in [Initial Proposal 2.2.1-1]-TP3 in R1-2207687.

Final CR (38.214, Rel-17, CR#0307r1, Cat F) is agreed in R1-2208126

R1-2208126 CR on the description about HARQ-feedbackEnablingforSPSactive in 38.214 Moderator (ZTE), Huawei, HiSilicon, ASUSTek, Xiaomi, OPPO, Ericsson

Agreement

· Adopt the TP in Proposal 2.1 Alt-2:#TP4 for 38.212, Section 7.3.1.1.3 in R1-2207687.

Final CR (38.212, Rel-17, CR#0116r1, Cat F) is agreed in R1-2208127

R1-2208127 CR on DCI size for Rel-17 NTN HARQ in 38.212 Moderator (ZTE), Huawei, HiSilicon, ASUSTek, Xiaomi, OPPO, Ericsson

RAN1#110-bis-e

8.44 Maintenance on Solutions for NR to support non-terrestrial networks (NTN)

R1-2210680 Session notes for 8.4 (Maintenance on Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Huawei)

[110bis-e-R17-NR-NTN-01] – Mohamed (THALES)

Email discussion to determine maintenance issues to be handled in RAN1#110bis-e by October 12

- Additional email discussions will be set up once the maintenance issues for RAN1#110bis-e are determined

R1-2210436 Summary of [110bis-e-R17-NR-NTN-01] Email discussion to determine maintenance issues to be handled in RAN1#110bis-e

Decision: As per email decision posted on Oct 12th,

Conclusion of [110bis-e-R17-NR-NTN-01]:

For Rel-17 maintenance, the following the issues described in R1-2210436 are to be handled at RAN1#110bis-e:

· For timing relationship enhancements and UL time and frequency synchronization for NR NTN: 1-6, and 1-4 (as recommendation for editor’s alignment CR)

· For scheduling and HARQ for NR NTN: 2-2, 2-3, and 2-1 (as recommendation for editor’s alignment CR)

Note: From Oct 13th email decision, issue 1-1 (UE backward propagation of the orbit and common TA) is part of [110bis-e-R17-NR-NTN-02] email thread for clarifying whether the issue is essential.

The following draft CRs are not pursued in Rel-17: R1-2208830, R1-2210046, R1-2210047.

R1-2208830 Draft CR on interpretation SFN indicating epoch time OPPO

R1-2210046 Draft CR for 38.211 to ensure correct interworking between open and closed loop TA Nokia, Nokia Shanghai Bell

R1-2210047 Draft CR for 38.213 to capture correct validity timer expiry behavior for UL synchronization Nokia, Nokia Shanghai Bell

R1-2209823 Correction on timing relationship parameter for NR NTN Huawei, HiSilicon

R1-2210045 Additional aspects of Rel-17 maintenance for NR over NTN Nokia, Nokia Shanghai Bell

R1-2210048 Draft CR for 38.213 to clarify calculation and application of timing advance values for common TA and UE specific TA Nokia, Nokia Shanghai Bell

R1-2208829 Discussion on remaining issue for NTN-NR OPPO

R1-2209654 On the validity of assistance information for R17 NR NTN Ericsson

R1-2210019 Remaining issues on solutions for NR to support NTN Lenovo

[110bis-e-R17-NR-NTN-02] – Mohamed (Thales)

Email discussion for maintenance on timing relationship enhancements and UL time and frequency synchronization for NR NTN for issues 1-6, issue 1-4 (as recommendation for editor’s alignment CR), and issue 1-1 (for clarifying whether the issue is essential) in R1-2210436

- Check points: October 14, October 19

R1-2210580 Summary#1 of [110bis-e-R17-NR-NTN-02] Email discussion for maintenance on timing relationship enhancements and UL time and frequency synchronization for NR NTN for issues 1-6, 1-1 and 1-4. Moderator (Thales)

Decision: As per email decision posted on Oct 15th,

For alignment TS38.213 CR:

Text proposal of Initial Proposal 1-4-1 provided in section 2.2 of R1-2210580 on aligning the name of kmac in TS 38.213 and TS 38.331 is endorsed for the editorial corrections.

Final summary in R1-2210581.

R1-2208993 Correction on determination of the number of HARQ-ACK information bits for NTN Langbo

R1-2208994 Correction on Type-2 HARQ-ACK codebook in PUSCH for NTN Langbo

R1-2208886 Draft CR on the indication of downlink disabled HARQ feedback for NR NTN vivo

[110bis-e-R17-NR-NTN-03] – Nan (ZTE)

Email discussion for maintenance on scheduling and HARQ for NR NTN for issues 2-2, 2-3, and 2-1 (as recommendation for editor’s alignment CR) in R1-2210436

- Check points: October 14, October 19

R1-2210587 Summary#1 of maintenance on HARQ for Rel-17 NR-NTN Moderator (ZTE)

Decision: As per email decision posted on Oct 15th,

For alignment TS38.213 CR:

Text proposal provided in R1-2208886 Draft CR to 38.213 on the indication of downlink disabled HARQ feedback for NR NTN is endorsed for the editorial corrections.

Agreement

· The following two TPs are endorsed in principle.

[Updated Proposal 1.1-1] for (38.213, Section 9.1.3.1)

Reason for change:

DAI value is defined based on PDSCH receptions, excluding PDSCH receptions that provide only transport blocks for HARQ processes associated with disabled HARQ-ACK information if donwlinkHARQ-FeedbackDisabled is provided. The total number of DCI formats (i.e., ) used for calculating the number of HARQ-ACK information bits for PUCCH power control should also exclude the DCI formats scheduling PDSCH receptions without associated HARQ-ACK information.

Summary of change:

The DCI formats scheduling PDSCH receptions without associated HARQ-ACK information are excluded for the calculation of the total number of DCI formats (i.e., ) for PUCCH power.

Consequences if not approved:

The UE may use an underestimated power to transmit PUCCH.

----------------------------------------Start of TP 38.213 V17.3.0 section 9.1.3.1 ---------------------------------------------

9.1.3.1 Type-2 HARQ-ACK codebook in physical uplink control channel

- or , for G-RNTI or G-CS-RNTI , is the total number of DCI formats scheduling PDSCH receptions providing transport blocks with enabled HARQ-ACK information, or having associated HARQ-ACK information without scheduling a PDSCH reception, that the UE detects within the or PDCCH monitoring occasions, respectively, for serving cell . or if the UE does not detect any DCI format scheduling PDSCH reception providing a transport block with enabled HARQ-ACK information, or having associated HARQ-ACK information without scheduling PDSCH reception, for serving cell in any of the or , respectively, PDCCH monitoring occasions.

----------------------------------------End of TP 38.213 V17.3.0 section 9.1.3.1 ---------------------------------------------

[Updated Proposal 2.1-1] for (38.213, Section 9.1.3.2)

Reason for change:

UE has to always multiplex HARQ-ACK information for PDSCH receptions with disabled HARQ-ACK information in PUSCH even if UL DAI value when the UE has received a PDCCH scheduling PDSCH receptions with disabled HARQ-ACK information.

Summary of change:

Change the condition for disabling multiplexing HARQ-ACK information in PUSCH transmission in case UL DAI value by excluding the PDCCH scheduling PDSCH receptions with disabled HARQ-ACK information.

Consequences if not approved:

UL DAI value cannot disable the multiplexing of HARQ-ACK information for PDSCH receptions with disabled HARQ-ACK information in PUSCH.

----------------------------------------Start of TP 38.213 V17.3.0 section 9.1.3.2 ---------------------------------------------

9.1.3.2 Type-2 HARQ-ACK codebook in physical uplink shared channel

If a UE is not provided PDSCH-CodeBlockGroupTransmission and the UE is scheduled for a PUSCH transmission by DCI format that includes a DAI field with value and the UE has not received any PDCCH within the monitoring occasions for a DCI format scheduling PDSCH receptions providing transport blocks with enabled HARQ-ACK information or having associated HARQ-ACK information without scheduling PDSCH receptions on any serving cell , and the UE does not have HARQ-ACK information in response to a SPS PDSCH reception to multiplex in the PUSCH as described in clause 9.1.3.1, the UE does not multiplex HARQ-ACK information in the PUSCH transmission.

If a UE is provided PDSCH-CodeBlockGroupTransmission and the UE is scheduled for a PUSCH transmission by DCI format that includes a DAI field with first value or with second value and the UE has not received any PDCCH within the monitoring occasions for a DCI format scheduling PDSCH reception providing a transport block with enabled HARQ-ACK information or having associated HARQ-ACK information without scheduling PDSCH reception on any serving cell , and the UE does not have HARQ-ACK information in response to a SPS PDSCH reception to multiplex in the PUSCH, as described in clause 9.1.3.1, the UE does not multiplex HARQ-ACK information for the first sub-codebook or for the second sub-codebook, respectively, in the PUSCH transmission.

----------------------------------------End of TP 38.213 V17.3.0 section 9.1.3.2 ---------------------------------------------

R1-2210588 CR on the Type-2 HARQ-ACK codebook Moderator (ZTE)

Decision: As per email decision posted on Oct 18th,

Agreement

The draft CR in R1-2210588 to reflect above agreement is endorsed in principle with the following correction:

· Addition of “with” in clause 9.1.3.2: “providing transport blocks with enabled HARQ-ACK information”

Final CR (TS38.213, Rel-17, CR#0375, Cat F) is agreed in:

R1-2210589 CR on the Type-2 HARQ-ACK codebook Moderator (ZTE), Ericsson, Nokia, Thales

RAN1#111

8.44 Maintenance on Solutions for NR to support non-terrestrial networks (NTN)

R1-2212834 Session notes for 8.4 (Maintenance on Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Huawei)

Endorsed and contents incorporated below.

[111-R17-NR_NTN] – Mohamed (Thales)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2212613 FL Summary #1: Maintenance on Solutions for NR to support NTN Moderator (Thales)

UE backward propagation of the ephemeris and common TA (Issue#1 in R1-2212613)

R1-2210870 Discussion on UE backward propagation of the ephemeris and common TA Huawei, HiSilicon

R1-2212313 On epoch time and validity of assistance information for R17 NR NTN Ericsson

R1-2212399 Remaining aspects of Rel-17 maintenance for NR over NTN Nokia, Nokia Shanghai Bell

Conclusion

The UE may consider assistance information valid as soon as it is received. No specification impact is expected. The current definition of validity duration is not changed based on this conclusion.

Correction for UE performing pre-compensation (Issue#2 in R1-2212613)

R1-2211456 Draft CR on correction for UE performing pre-compensation OPPO, Apple

Calculation and application of timing advance values for common TA and UE specific TA (Issue#3 in R1-2212613)

R1-2212399 Remaining aspects of Rel-17 maintenance for NR over NTN Nokia, Nokia Shanghai Bell

R1-2212400 Draft CR for 38.213 to clarify calculation and application of timing advance values for common TA and UE specific TA Nokia, Nokia Shanghai Bell

Corrections on RRC parameter name alignment for NR NTN in TS38.213 (Issue#4 in R1-2212613)

R1-2212311 Corrections on RRC parameter name alignment for NR NTN in TS38.213 Sharp

Agreement

The TP in Updated Proposal 4 in section 4.3 of R1-2212613 is endorsed and provided to the TS 38.213 editor for aligning the name of CellSpecific_Koffset, Koffset, and HARQ-feedbackEnablingforSPSactive in TS 38.213 with the names of these parameters in TS 38.321.

Final summary in:

R1-2212614 FL Summary #2: Maintenance on Solutions for NR to support NTN Moderator (Thales)

From AI 5

R1-2210809 LS on validity of assistance information RAN2, OPPO

R1-2212774 Discussion on reply to RAN2 LS on validity of assistance information Moderator (OPPO)

R1-2212929 [Draft] reply LS on validity of assistance information OPPO

Decision: The draft LS in R1-2212929 is endorsed, with correction of the next meeting dates. Final LS is approved in R1-2212984.

RAN1#112

8.44 Maintenance on Solutions for NR to support non-terrestrial networks (NTN)

R1-2302054 Session notes for 8.4 (Maintenance on Solutions for NR to support non-terrestrial networks (NTN)) Ad-Hoc Chair (Huawei)

[112-R17-NR_NTN] – Mohamed (Thales)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2301907 FL Summary #1: Maintenance on Solutions for NR to support NTN Moderator (Thales)

Presented in Tuesday session

R1-2301908 FL Summary #2: Maintenance on Solutions for NR to support NTN Moderator (Thales)

Presented in Thursday session

Issue#1 Draft CR 38.211: Correction of timing advance and alignment to 38.331

R1-2301741 Draft CR 38.211: Correction of timing advance and alignment to 38.331 Ericsson

R1-2301738 Maintenance issues for R17 NR NTN Ericsson

Decision: Comeback later in the week

Conclusion

· The draft CR in R1-2301741 is not pursued in Rel-17.

Issue#2: Draft CR 38.212: Alignment with 38.331

R1-2301742 Draft CR 38.212: Alignment with 38.331 Ericsson

R1-2301738 Maintenance issues for R17 NR NTN Ericsson

Conclusion

· The TP in section 2.3 of R1-2301907 is endorsed as editorial correction and provided to the editor of TS38.212 for the alignment CR.

Issue#3: Draft CR 38.213: Addition of missing parameter dl-DataToUL-ACK-v1700

R1-2301743 Draft CR 38.213: Addition of missing parameter dl-DataToUL-ACK-v1700 Ericsson

R1-2301738 Maintenance issues for R17 NR NTN Ericsson

Conclusion

· The TP in section 3.3 of R1-2301907 is endorsed as editorial correction and provided to the editor of TS38.213 for the alignment CR.

Issue#4: Draft CR on the Type-1 HARQ-ACK codebook

R1-2300260 Draft CR on the Type-1 HARQ-ACK codebook OPPO

Decision: Comeback later in the week

Agreement

Endorse the draft CR in R1-2300260.

R1-2302182 Draft CR on the Type-1 HARQ-ACK codebook Moderator (Thales)

Decision: The draft CR is endorsed. Final CR (Rel-17, 38.213, CR0458, Cat F) is agreed in

R1-2302229 CR on the Type-1 HARQ-ACK codebook Moderator (Thales), OPPO, NTT DOCOMO, Xiaomi, Samsung, Ericsson

Issue#5: Draft CR on the Type-2 HARQ-ACK codebook

R1-2300261 Draft CR on the Type-2 HARQ-ACK codebook OPPO

Decision: Comeback later in the week

Conclusion

· The draft CR in R1-2300261 is not pursued in Rel-17.

Final summary in R1-2301909.